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Abstract 


This  report  presents  the  design  and  implementation  of  a  device¬ 
independent,  general-purpose  interactive  graphics  system.  The  sys¬ 
tem  allows  the  high-level  creation  and  manipulation  of  both  line 
drawing  and  area  shaded  pictures  on  a  variety  of  refresh,  storeige, 
and  raster  scan  displays.  Real-time  graphical  input  facilities  are 
available  for  stylus  tracking  and  inking,  light  button  interactions, 
and  device  polling.  The  system  is  implemented  on  a  PDF  11/45  mini¬ 
computer  running  the  UNIX  time-sharing  system. 


A  chnozuledgments 


Many  people  have  helped  in  the  development  of  this  system.  Ron  Baecker,  my  supervi¬ 
sor,  was  always  available  with  helpful  suggestions  and  encouragement.  Any  resem¬ 
blance  this  document  has  to  modern  English  is  through  the  efforts  of  Ron  and  my 
second  reader,  Les  Mezei.  Tom  Horsley  has  contributed  the  Colour  Video  System 
driver,  a  scan  converter,  and  much  of  the  development  behind  standard  graphics  for¬ 
mat.  Mike  Tilson  developed  the  Versatec  driver  and  worked  with  Tom  Duff  and  myself 
in  writing  another  scan  converter.  The  character  recognizer  is  the  work  of  SheUa  Cros- 
sey.  David  Tilbrook  developed  the  “interp”  routine  emd  support  package  for  GPAC. 
These  people  along  with  the  remaining  members  of  the  Dynamic  Graphics  Project,  Greg 
Hill,  Robert  Pike,  and  Martin  Tuori,  have  all  contributed  greatly  to  the  system  by  being 
constantly  interested  in  its  development  and  by  actually  using  it  in  their  applications.  I 
would  like  to  thank  the  entire  group  for  the  many  suggestions  they  made  and  the  many 
bugs  they  found.  The  National  Research  Council  of  Canada  has  been  very  kind  in  pro¬ 
viding  financial  support  during  the  system’s  development. 


Preface 


The  first  four  chapters  of  this  report  are  based  on  the  author’s  M.Sc.  thesis,  presented 
to  the  Department  of  Computer  Science  in  January  1976.  The  graphics  system 
described  herein  has  developed  further  since  that  time,  as  reflected  in  chapter  five  and 
the  Users’  Manual  in  Appendix  A. 
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1.  Goals 


Small  scale  time-sharing  systems  based  on  minicomputers  are  becoming  predominant 
in  today’s  computer  installations.  Interactive  graphics  is  also  growing  in  popularity 
with  computer  users  involved  in  data  processing,  numerical  analysis,  computer  art, 
and  numerous  other  applications.  The  design  and  implementation  of  an  interactive 
graphics  system  within  a  minicomputer  time-sharing  environment  is  discussed  in  this 
report.  The  term  graphics  system  is  used  here  to  mean  a  collection  of  software  which 
allows  the  high-level  implementation  of  graphics  programs. 

Early  in  1975,  the  Dynamic  Graphics  Project  of  the  Computer  Systems  Research  Group 
at  the  University  of  Toronto  started  to  transfer  all  its  computing  from  a  large,  batch- 
oriented  IBM  370  to  a  PDP  11/45  minicomputer  running  the  UNIX  Time-sharing  system. 
The  following  goals  were  defined  for  providing  graphics  capabilities  under  UNIX: 

1.  High-level  user  interface 

2.  General-purpose 

3.  Device-independent 

4.  Real-time  response 

5.  Preserve  time-sharing 

6.  Preserve  UNIX  philosophy 

7.  Efficient  implementation 

The  remainder  of  this  chapter  discusses  why  these  goals  were  chosen.  Chapter  2 
presents  a  brief  background  on  other  graphics  systems  and  the  environment  in  which 
this  system  was  created.  The  user  interfaces  of  the  system  are  presented  in  chapter  3. 
Chapter  4  discusses  the  implementation.  Conclusions  are  drawn  in  chapter  5. 

A  graphics  system  needs  a  well-designed  user  interface.  It  has  to  be  clean,  easy  to 
learn,  and  easy  to  use.  The  tools  must  be  powerful,  yet  concise  and  simple.  The  user 
interface  must  be  high-level,  hiding  the  low-level  hardware  dependent  features  of 
graphics  devices.  The  user  should  be  able  to  use  the  system  through  a  high-level, 
general-purpose  programming  language. 

The  graphics  system  must  be  general-purpose  to  support  varied  applications.  If  a 
design  is  made  in  which  the  application  areas  are  known,  certain  optimizations  may  be 
possible.  However,  if  unexpected  applications  are  later  begun,  it  may  be  necessary  to 
make  awkward  changes  or  to  write  a  totally  new  system.  Areas  of  application  in  our 
group  currently  include  ein  animation  system,  a  newspaper  page  layout  system,  a  cir¬ 
cuit  design  system,  a  simulation  system  having  graphic  output,  a  sketch  editor,  a  char¬ 
acter  recognizer,  a  system  representing  hand-drawn  curves  with  cubic  splines  and  her- 
mite  polynomials,  a  three  dimensional  architecture  system,  and  various  computer 
games.  Thus  a  graphics  system  in  this  environment  must  provide  a  general  set  of  tools 
from  which  users  can  build  their  own  systems. 

✓ 

In  a  device-independent  system,  the  software  is  written  so  that  it  can  support  various 
graphics  terminals  in  various  configurations.  In  the  past,  the  arrival  of  a  new  terminal 
has  often  necessitated  the  development  of  a  new  software  system  to  meet  its  particular 
needs.  The  design  and  implementation  of  this  software  is  an  expensive  and  time  con¬ 
suming  effort.  Only  a  few  hardware-dependent  routines  need  be  written  to  incorporate 
a  new  terminal  into  a  device-independent  system.  Thus  the  software  maintenance 
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costs  will  be  reduced.  Device-independent  systems  also  aillow  a  program  to  switch 
easily  from  one  device  to  another.  This  is  especially  useful  when  a  device  is  broken  or 
in  use  by  someone  else.  In  a  device-dependent  system,  users  can  be  very  confused 
with  differences  between  devices  and  their  associated  support  packages  because  each 
has  its  own  documentation,  conventions,  and  interfaces.  Sometimes  users  aure  afraid  to 
switch  to  a  different  device  in  the  fear  that  they  will  get  the  old  and  new  systems  rmxed 
up.  The  hardware  configuration  for  this  system  includes  refresh,  storage,  and  raster 
scan  graphics  devices,  so  the  need  for  a  device-independent  system  was  clear. 

In  an  interactive  system,  the  response  time,  the  time  taken  by  the  computer  to  reply 
to  a  user  interaction,  is  very  critical.  Delays  of  a  few  seconds  are  often  unacceptable. 
It  is  sometimes  even  necessary  to  demand  real-time  response.  For  example,  real-time 
playback  in  an  animation  system  demands  that  a  new  frame  of  the  film  appear  on  the 
screen  every  24th  of  a  second.  Thus  we  need  to  be  able  to  ensure  that  certain  pro¬ 
grams  can  get  all  the  system  resources  they  need. 

The  easiest  and  most  efficient  way  to  achieve  the  above  goal  would  be  to  run  a  single- 
user  system.  Without  other  programs  running  at  the  same  time,  the  program  would 
have  complete  control.  But  we  want  the  beauty  and  productivity  of  time-sharing,  allow¬ 
ing  multiple  users  to  work  at  the  same  time,  sharing  the  resources  of  the  machine,  but 
having  the  illusion  that  they  have  the  machine  to  themselves.  Thus  the  preservation  of 
time-sharing  is  adopted  along  with  the  real-time  response  goal.  What  is  really  expected 
is  a  compromise,  letting  a  user  and  his  program  become  privileged  and  get  real-time 
response,  but  only  when  absolutely  necessary,  and  then  serving  other  users’  needs  with 
the  available  remaining  resources. 

UNIX  had  no  graphics  facilities  when  it  arrived.  It  was  apparent  that  sizable 
modifications  and  additions  would  be  necessary.  These  changes  should  be  in  the  style 
of  the  original,  and  should  be  localized  as  much  as  possible  so  that  upgrading  the  sys¬ 
tem  for  subsequent  UNIX  releases  is  as  painless  as  possible.  There  are  many  ideas  in 
the  philosophy  of  UNIX  which  make  it  very  appealing  as  an  operating  system.  For 
example,  UNIX  is  written  in  a  high-level  programming  language.  Another  example  is  its 
treatment  of  hardware  devices  as  just  a  special  kind  of  file  which  can  be  read  or  writ¬ 
ten.  UNIX  was  also  written  with  the  capabilities  of  the  machine  in  mind.  In  many  cases 
one  design  was  adopted  instead  of  another  because  the  hardwaire  would  not  be  able  to 
handle  the  latter  adequately. 

Efficient  implementation  is  desired  in  all  projects.  In  our  minicomputer  environment, 
however,  it  is  critical.  Hardware  limitations  of  total  memory  size,  memory  bandwidth, 
program  address  size,  CPU  speed,  and  disk  speed  are  all  very  apparent  on  a  minicom¬ 
puter,  especially  when  doing  heavy  or  real-time  computing. 

It  was  fairly  obvious  that  one  cannot  develop  a  design  and  implementation  to  satisfy  all 
the  goals  concurrently.  They  are  used  only  as  guidelines.  Many  tradeoffs  must  be 
made  to  arrive  at  the  final  system.  In  some  cases  efficiency  is  sacrificed  for  general- 
purpose  considerations.  In  others,  the  opposite  is  true,  where  a  proposed  design  would 
take  too  much  memory  or  too  many  CPU  cycles  to  be  feasible  in  a  minicomputer  time¬ 
sharing  system. 
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2.  Background 


This  chapter  presents  a  brief  description  of  other  graphics  systems  that  have  had  a 
major  influence  on  the  design  discussed  in  this  report.  Then  a  description  of  the 
hardware  and  software  available  for  the  work  is  given. 


2.1.  Graphics  Systems 

2.1.1.  APEX 

The  APEX  time-sharing  system  [Sutherland  69]  developed  at  the  M.I.T.  Lincoln  Labora¬ 
tory  on  its  TX-2  computer  was  one  of  the  earliest  attempts  at  providing  graphics  on  a 
time-sharing  system.  APEX  had  the  capability  of  simultaneously  supporting  up  to  five 
refresh  terminals  at  once  with  “acceptable  flicker”.  These  displays  were  refreshed 
directly  from  a  structured  display  file  in  main  core  by  a  single  vector  generator  which 
was  time-shared  on  a  frame  to  frame  basis.  APEX  performed  picture  structuring, 
dynamic  storage  allocation,  and  garbage  collection  automatically  for  the  user.  Struc¬ 
turing  was  based  on  the  concepts  of  groups  and  items.  An  item  was  a  collection  of 
points,  lines,  curves  or  characters  with  an  identifying  name.  A  group  was  an  identified 
collection  of  items  and  other  groups.  APEX  handled  interactive  input  from  various 
input  devices  including  light  pens,  tablets,  knobs,  switches,  and  pushbuttons.  User 
programs  would  request  and  receive  input  services  from  the  APEX  input  monitor.  Con¬ 
ditions  were  specified  under  which  APEX  would  interrupt  user  programs  to  provide  the 
requested  information  stored  in  an  accessible  buffer.  A  high-level  language,  LEAP,  con¬ 
taining  associative  data  structuring  operations,  and  reserved  procedures  for  display  or 
input  manipulation,  was  developed  as  an  alternative  to  assembly  coding  and  communi¬ 
cating  with  APEX  in  a  hardware  dependent  manner. 


2.1.2.  Omnigraph 

The  Omnigraph  system  [Sproull  74],  implemented  on  a  PDP-10  time-sharing  system  at 
the  Computer  Centre  of  the  National  Institutes  of  Health,  was  designed  to  be  a  device¬ 
independent  system  using  a  wide  variety  of  storage  and  refresh  line-drawing  displays. 
Interactive  input  devices  included  tablets,  lights,  buttons,  and  cross  hairs.  Omnigraph 
was  written  as  a  set  of  subroutines  callable  from  FORTRAN,  LISP,  and  SAIL.  Much 
attention  was  given  to  user  interfaces,  and  to  providing  a  clean  and  concise  set  of 
powerful  routines.  The  display  file  organization  used  by  Omnigraph  is  called  a  seg¬ 
mented  transformed  display  file.  Pictures  were  broken  into  separate  segments  which 
were  handled  independently.  When  a  segment  was  created  it  was  transformed  and 
placed  in  the  transformed  display  file.  To  retransform  a  segment,  the  user  had  to 
recreate  it  with  a  different  transformation  in  effect. 
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2.1.3.  PICO 


PICO  [Newman  75]  was  a  graphics  package  developed  at  Xerox  Palo  Alto  Research  Cen¬ 
tre  for  three  different  raster  scan  displays,  and  designed  to  be  callable  from  BCPL, 
Smalltalk  and  INTERLISP.  Techniques  used  for  constructing  general-purpose,  device¬ 
independent,  line-drawing  graphics  systems  used  in  Omnigraph  and  presented  in  [New¬ 
man  73B]  were  extended  to  produce  output  on  both  colour  and  gray-level  raster  scan 
devices.  PICO  allowed  the  definition  and  display  of  solid  opaque  objects  and  contained 
algorithms  for  resolving  which  of  two  overlapping  objects  should  be  visible.  PICO  also 
contained  an  event  driven  input  scheme  for  such  input  devices  as  mice,  tablets,  but¬ 
tons,  and  keyboards. 


2.2.  Out  Environment 


2.2.1.  Hardware 

The  centred  processor  (CPU)  is  a  PDP  11/45  [DEC  73]  with  64K  16  bit  words  of  core 
memory,  and  in  the  very  near  future  to  be  increased  to  96K.  Its  memory  is  byte  (8  bit) 
addressable.  The  11/45  is  one  of  the  fastest  and  largest  general-purpose  minicomput¬ 
ers  commercially  available.  It  has  a  highly  sophisticated  instruction  set  with  average 
cycle  time  of  one  to  two  microseconds,  and  a  novel  single  bus  architecture  known  as 
the  Unibus.  Our  configuration  also  has  a  floating  point  processor.  The  11/45  can  run  at 
any  of  7  priorities  and  in  one  of  3  modes  which  are,  in  order  of  decreasing  privileges: 
kernel,  supervisor,  and  user.  For  each  mode  there  are  two  separate  sets  of  memory 
management  registers  to  map  16  bit  logical  addresses  into  18  bit  physical  core  loca¬ 
tions.  One  set  is  used  to  address  program  data;  the  other  set  is  used  to  address  pro¬ 
gram  instructions.  Thus  the  11/45  can  access  a  maximum  of  128K  words  of  physical 
memory,  while  a  program  running  in  one  of  the  modes  can  have  a  maximum  of  32K 
words  of  data  and  32K  words  of  instructions.  The  memory  management  is  designed  for 
a  paging  environment  with  each  set  of  16  registers  specifying  for  each  4K  of  logical 
address  space  (either  instructions  or  data)  its  location  in  physical  core,  the  length  in 
blocks  of  32  words,  and  its  various  protection  bits  and  reference  counts.  If  a  portion  of 
a  program’s  logical  address  space  is  not  in  core,  the  memory  management  system  cam 
cause  ah  interrupt  signifying  a  page  fault. 

The  11/45  has  a  priority  interrupt  mechanism  used  by  devices  to  signal  the  CPU  about 
some  asynchronous  event.  Depending  on  the  urgency  of  their  events,  devices  interrupt 
at  different  priorities.  By  setting  the  processor  priority,  interrupts  of  equal  or  lower 
priority  can  be  withheld  until  the  processor  priority  is  lowered.  When  an  interrupt 
request  is  granted,  the  current  state  of  the  processor  is  saved  so  that  the  task  can  be 
resumed  when  the  interrupt  has  been  serviced.  For  each  interrupt  there  is  a  location 
in  which  to  store  the  address  of  an  interrupt  service  routine  which  is  called  whenever 
the  interrupt  request  is  granted. 

The  configuration  has  two  moving-head  disk  systems,  made  by  Diva  and  System  Indus¬ 
tries.  The  Diva  can  only  transfer  one  block  (512  bytes)  with  a  single  I/O  operation;  the 
SI  is  capable  of  multi-sector  transfers  of  up  to  64,000  bytes  with  one  I/O  operation.  A 
1600  BPI  Wangco  tape  unit  is  the  other  major  mass  storage  device  available.  A  conven¬ 
tional  line  printer  and  four  assorted  terminals  are  the  remaining  non-graphics 
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hardware  devices. 


Our  major  graphics  display  is  a  "Graphic  Wonder"  [Rosen  74]  made  by  Three  Rivers 
Computer  Corporation.  It  is  a  line-drawing  display  capable  of  drawing  over  50,000  vec¬ 
tors  in  1/80  of  a  second.  The  display  is  refreshed  directly  out  of  special  double-port 
memory  which  allows  the  display  processor  access  to  display  file  instructions  without 
tying  up  the  Unibus.  The  display  processor  accesses  the  double-port  through  its  own 
memory  management  system,  which  allows  each  IK  word  page  of  memory  to  be  relo¬ 
cated  to  any  IK  word  boundary  of  address  space. 

When  not  in  use  for  graphics,  the  double-port  functions  as  normal  memory.  Because 
the  display  processor  is  so  fast,  and  the  display  file  instructions  so  efllcient,  the 
Graphic  Wonder  does  all  its  character  processing  in  software.  The  user  provides  a 
sequence  of  relative  vector  instructions  for  each  character,  and  a  dispatch  table  speci¬ 
fying  where  each  of  these  character  definitions  resides  in  the  display  file.  The  Graphic 
Wonder  has  16  levels  of  intensity  and  16  levels  of  hardware  scaling.  It  performs 
hardware  scissoring  but  not  clipping.  No  high-level  transformations  such  as  three- 
dimensional  rotations  are  provided  in  the  hau-dware.  The  Graphic  Wonder  is  equipped 
with  a  keyboard  which  is  really  a  separate  device.  All  communication  between  the 
screen  and  keyboard  must  be  performed  in  software. 

A  raster  scan  colour  video  system  will  soon  be  added  to  our  configuration.  The  basic 
system  is  being  built  by  Three  Rivers  Computer  Corporation.  This  is  to  be  greatly 
enhanced  by  our  group.  It  also  refreshes  from  double-port  memory,  which  stores  the 
picture  as  a  256  by  256  grid,  each  pixel  or  grid  position  being  one  of  256  fixed  colours. 
Enhancements  that  are  planned  will  include  a  colour  map  allowing  approximately  one 
billion  different  colours,  display  instructions  describing  the  pictures  in  run  length 
encoded  format,  and  a  partial  hardware  solution  to  the  2  1/2  dimensional  hidden  sur¬ 
face  problem  [Baecker  78].  In  the  2  1/2  dimensional  hidden  surface  problem,  all  sur¬ 
faces  are  defined  in  planes  parallel  to  the  x-y  plane.  There  are  no  intersections  of  sur¬ 
faces  but  overlapping  is  possible.  Each  surface  has  a  depth  associated  with  it  which  is 
used  to  determine  which  surfaces  overlap  others. 

A  Tektronix  4013  display  is  also  connected  to  our  system.  It  is  a  storage  tube  display 
and  thus  does  not  need  to  be  refreshed  out  of  memory.  The  Tektronix  can  draw  any 
number  of  vectors  but  it  is  not  selectively  eraseable  and  takes  two  seconds  to  erase.  It 
has  a  fixed  hardware-defined  character  set  and  comes  equipped  with  a  keyboard  and  a 
pair  of  thumb  wheel  controlled  cross  hairs  which  can  be  used  for  interactive  input. 

The  only  on-line  graphic  hardcopy  device  on  the  system  is  a  Versatec  Printer-Plotter,  a 
raster  scan  black  and  white  device.  The  Versatec  will  operate  in  either  Print  mode, 
where  it  accepts  and  outputs  characters  in  a  fixed  hardware  defined  font,  or  in  Plot 
mode,  where  it  accepts  bits  defining  scan  lines  in  a  picture.  If  a  bit  is  on,  a  small  dot  is 
produced  at  its  corresponding  position  on  the  output  paper.  This  character  or  bit  infor¬ 
mation  is  given  to  the  Versatec  in  large  sections  in  a  buffer.  This  buffer  mush  be 
located  in  the  lower  32K  of  physical  core  as  unfortunately  the  hardware  contains  no 
memory  meinagement  module.  Intensities  must  be  handled  in  software  by  forfeiting 
some  resolution. 
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We  have  an  off-line  connection  to  a  Calcomp  B35  Microfilm  Plotter  producing  16  mm 
black  and  white  sprocketed  film.  The  current  connection  is  via  magnetic  tape  which  is 
carried  across  the  room  to  a  stand-alone  system  driving  the  Calcomp.  In  the  future, 
communication  will  be  over  a  high  speed  line  connected  to  a  DEC  LSI-11  microcom¬ 
puter  which  will  drive  the  plotter.  The  Calcomp  is  only  a  point  plotter,  hence  each  vec¬ 
tor  must  be  broken  into  a  series  of  points.  It  has  32  intensity  levels,  although  at  most 
25  are  discernible. 

The  only  significant  input  device  avedlable  on  our  system  is  a  Summagraphics  Digitizing 
Tablet.  Two-dimensional  coordinate  information  is  indicated  with  either  a  stylus  or  a 
cursor  on  the  tablet  surface.  Both  are  equipped  with  one  primary  button  (called  the  Z 
axis  button)  and  3  secondary  buttons  which  a  user  can  depress.  The  Z  axis  is  actually  a 
switch  at  the  tip  of  the  stylus  or  a  button  on  the  cursor.  The  tablet  interrupts  the  CPU 
at  a  manually  selected  sampling  rate  of  up  to  200  interrupts  per  second.  At  each  inter¬ 
rupt  the  binary  status  of  all  the  buttons  and  the  x-y  position  of  the  stylus  is  available 
from  the  hardware.  The  tablet  can  detect  when  the  stylus  is  out  of  range  (it  is  more 
than  1/4  inch  from  the  tablet’s  surface),  and  when  there  is  an  overrun  (an  interrupt  is 
not  serviced  by  the  CPU  before  the  next  one  occurs). 


2.2.2.  Software 

The  operating  system  acquired  to  run  this  hardware  was  the  UNIX  Time-sharing  system 
[Thompson  74]  from  Bell  Laboratories.  Being  a  small  group,  we  could  not  afford  to 
build  our  own  graphics  operating  system,  and  we  also  wanted  to  have  compatibility  with 
other  UNIX  installations.  So  we  hoped  to  embed  graphics  capabilities  into  UNIX  with 
only  slight  modifications  to  the  system. 

UNIX  is  a  time-sharing  system.  Each  user  has  at  any  time  one  or  more  processes  exe¬ 
cuting,  possibly  an  editor  process,  a  command  interpreter  process,  a  compiler  pro¬ 
cess,  or  a  user  program.  Processes  can  spawn  other  processes  by  “forking”.  This 
creates  a  child  process,  an  exact  copy  of  its  peirent.  To  a  user,  a  process  is  a  program 
being  executed.  To  UNIX  it  is  a  set  of  machine  code  instructions  to  be  executed,  a  set 
of  data  values  the  machine  code  accesses,  and  a  process  descriptor.  It  is  possible  for 
one  process  to  “exec”  another,  and  thus  replace  itself  with  another  executing  pro¬ 
gram.  There  are  primitives  called  “signals”  for  process  synchronization,  and  special 
files  called  “pipes”  for  interprocess  communication. 

Time-sharing  gives  the  illusion  of  running  all  processes  at  the  same  time,  but  the 
hardware  can  only  execute  one  process  at  a  time.  Thus  UNIX  has  a  scheduler  process 
which  tries  to  share  the  hardware  as  fairly  as  possible  among  all  the  active  processes. 
UNIX  uses  a  priority-based  scheduling  algorithm.  Processes  start  at  a  default  priority 
but  the  operating  system  may  raise  or  lower  their  priority  depending  on  what  resource 
requests  they  make.  Within  a  given  priority,  the  scheduler  shares  the  hardware  on  a 
round-robin  basis,  giving  each  process  a  time  slice  in  which  it  can  execute  before  the 
next  is  allowed  to  run. 

If  core  memory  were  unlimited,  the  scheduler  would  be  quite  trivial.  In  almost  every 
time-sharing  system  memory  is  insufficient,  so  swapping  must  be  introduced.  Swap¬ 
ping  must  occur  when  the  total  memory  requirements  of  all  active  processes  are 
greater  than  the  physical  memory  size.  The  scheduler  must  realize  when  there  are 
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processes  ready  to  run  on  the  swapping  disk,  and  swap  them  in,  swapping  others  out  if 
necessary  to  get  enough  memory.  Processes  are  swapped  out  on  a  first  in  first  out 
basis.  Processes  that  have  gone  to  sleep,  for  example  those  waiting  for  1/0,  will  be 
swapped  out  before  any  processes  that  still  wish  to  execute. 

To  swap  in  a  process,  memory  must  be  allocated  for  both  its  instruction  section  (cadled 
“text”  in  UNIX)  and  its  data  section  (which  includes  program  stack,  static  variables 
and  the  process  descriptor).  UNIX  forces  each  section  to  be  loaded  contiguously  in 
memory,  although  the  hardware  does  not  require  this.  This  results  in  simpler  core 
allocation  and  swapping  routines  but  causes  less  than  optimal  memory  utilization. 
UNIX  also  insists  that  all  of  a  process  be  in  core  before  it  can  execute. 

The  UNIX  file  system  is  hierarchical.  Everything  in  UNIX  seems  to  be  a  file.  Programs 
are  files  which  can  be  executed.  Program  source  and  data  are  stored  in  files.  User 
interfaces  to  devices  like  terminals,  Line  printers,  tapes,  and  disks  are  through  special 
device  files.  Directories  in  the  file  system  are  a  special  type  of  file.  UNIX  provides 
access  protection  for  all  files  in  the  system. 

For  each  device  added  to  the  hardware  configuration,  a  device  driver  needs  to  be  writ¬ 
ten  to  interface  the  hardware  to  UNIX.  Drivers  normally  handle  the  initialization  of  the 
device,  the  interrupts  generated  by  the  device,  and  requests  by  users  or  by  other  por¬ 
tions  of  the  operating  system  to  use  the  device  (e.g.,  Read,  Write,  or  Seek  on  a  Disk, 
and  Read  or  Write  on  a  Teletype).  The  user  interface  to  a  device  driver  is  through  the 
special  device  file  mentioned  above. 

The  operating  system  as  well  as  95%  of  all  system  software  is  written  in  C  [Ritchie  74],  a 
high-level  language  having  its  roots  in  ALGOL  and  BCPL.  An  optimizing  compiler  for  C 
comes  with  the  UNIX  system. 

The  UNIX  command  interpreter  is  called  the  “shell”.  In  addition  to  taking  a  command 
from  the  user  and  executing  a  program  to  perform  the  requested  function,  the  shell 
can  start  multiple  commands  at  once,  and  direct  the  standard  output  of  one  program 
to  be  the  standard  input  of  another. 

UNIX  system  software  also  includes  a  text  editor,  an  assembler,  text  formatters,  a  For¬ 
tran  compiler,  a  Basic  interpreter,  macro  processors,  compiler-compilers,  and 
numerous  other  systems  and  commands.  It  is  a  rich  and  powerful  environment  in 
which  to  write  programs.  The  remainder  of  this  report  will  describe  the  tools  added  to 
this  environment  to  allow  programs  to  do  graphics. 


3.  User  Interfaces 

This  chapter  describes  the  user  interfaces  of  the  graphics  system.  The  major  interface 
is  through  GPAC,  standing  for  Graphics  PACkage.  The  interfaces  of  the  graphic  wonder 
scroller  program  and  the  film  playback  program  are  also  discussed.  In  all  cases,  our 
design,  as  well  as  the  alternative  design  possibilities  that  were  rejected,  are  compared 
and  evaluated. 
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3.1.  GPAC 


GPAC  is  the  prime  user  interface  to  the  graphics  system.  As  the  name  suggests,  it  is  a 
package,  a  set  of  procedures  residing  in  ein  object  module  Library  file  eind  callable  from 
application  programs.  GPAC  is  used  with  the  programming  language  C,  which  satisfies 
the  goal  of  providing  a  user  interface  through  a  high-level  language.  The  only  other 
available  high-level  language  was  FORTRAN,  but  it  was  rejected  because  its  control 
structures  and  data  structures  hinder  structured  programming.  In  addition,  UNIX’s 
FORTRAN  implementation  compiles  poor  code.  We  also  rejected  the  approach  of 
designing  an  entirely  new  programming  language  because  it  would  have  involved  too 
much  work. 

Graphics  prograims  define  and  output  pictures  onto  a  display  screen  or  hard-copy  dev¬ 
ice,  and  they  receive  graphical  input  interactively  from  the  user.  In  GPAC,  the  input 
and  output  routines  are  relatively  independent  of  each  other.  The  foUomng  sections 
describe  the  output  and  input  user  interfaces.  For  a  more  detailed  description.  Appen¬ 
dix  A  contains  the  current  GPAC  Users’  Manual. 


3.1.1.  Output 

The  output  routines  of  GPAC  create  and  manipulate  pictures.  They  can  be  further  sub¬ 
divided  into  four  catagories:  graphical  primitives,  transformation  routines,  segment 
handling  routines,  and  film  creation  routines. 


3.1.1. 1,  Graphical  Primitives 

GPAC  provides  functions  that  let  the  user  define  lines  aind  display  character  strings. 
The  coordinates  of  a  line’s  endpoints  may  be  specified  absolutely  or  as  a  relative  dis¬ 
placement  from  the  previously  defined  point,  A  coordinate  value  may  be  any  floating 
point  number.  There  are  functions  for  setting  the  intensity  or  colour  of  subsequently 
drawn  lines.  For  raster  seem  devices,  there  are  routines  for  defining  areas  which  can 
be  filled  in  with  the  current  intensity  on  a  black  and  white  device  or  with  the  current 
colour  on  a  colour  device.  The  areas  are  defined  by  surrounding  a  sequence  of  line 
drawing  commands  which  define  the  area's  outline  with  two  routines  indicating  the 
beginning  and  end  of  an  area.  GPAC  ensures  that  all  such  areas  are  closed.  For  a  ras¬ 
ter  scan  device,  routines  are  also  provided  to  define  the  background  intensity  or  colour 
and  the  line  vddth.  On  raster  scan  devices  GPAC  performs  2  1/2  D  hidden  surface  elim¬ 
ination  on  overlapping  shaded  areas,  lines,  and  character  strings.  The  method  for 
deciding  what  areas  overlap  others  is  given  in  3. 1,1,3.  Routines  exist  which  will  save 
and  restore  the  current  colour,  intensity,  line  width,  and  the  x-y  positions  of  the 
current  point  on  an  internal  stack. 
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3. 1.1. 2,  Trans foTTnatixms 


GPAC  includes  transformation  routines  which  are  capable  of  translating,  seeding,  and 
rotating  graphic  information  produced  by  the  graphical  primitives.  These  routines  also 
clip  the  graphic  information  against  a  user-defined  rectangular  window  to  remove  parts 
of  the  picture  that  should  not  appear  on  the  screen,  and  then  map  the  remaining  pic¬ 
ture  onto  a  rectangular,  user-defined  viewport  defined  in  screen  coordinates.  Transfor¬ 
mations  are  very  important  for  users,  freeing  them  of  some  device-dependent  features 
such  as  screen  coordinate  sizes.  Transformations  can  be  used  in  the  generation  of 
repeated  symbols  at  varying  positions,  sizes,  and  orientations,  and  in  showing  different 
views  of  a  picture.  Finally,  transformations  allow  users  to  work  in  the  coordinate  space 
of  their  application,  be  it  light  years,  angstroms,  or  picas. 

The  user  informs  GPAC  what  transformations  are  to  be  applied  to  all  subsequent  graph¬ 
ical  information  by  calling  separate  functions  for  translating,  scaling,  eind  rotating. 
Each  function  updates  GPAC’s  current  transformation  matrix  which  transforms  all 
coordinate  pairs.  Arbitrary  rotation  angles  and  scaling  factors  are  accepted.  The 
transformations  are  applied  in  exactly  the  order  specified  by  the  user.  Thus  a 
rotation-translation  sequence  will  not  normally  produce  the  same  result  as  the  identi¬ 
cal  calls  given  in  reverse  order. 

An  alternative  to  supplying  separate  functions  for  the  transformations  is  to  provide  a 
routine  which  allows  the  user  to  specify  the  current  transformation  matrix  directly. 
Support  routines  which  generate  separate  matrices  representing  the  simple  transfor¬ 
mations  and  a  routine  to  multiply  them  together  would  also  have  to  be  supplied.  We 
rejected  this  approach  because  it  requires  the  user  to  understand  matrices  and  to 
multiply  them  together  in  the  correct  order. 

Still  another  approach  is  that  of  instance  rectangles,  in  which  a  two  dimensional 
transformation  is  specified  by  defining  the  position  and  size  of  a  master  picture  and  an 
instance  on  the  screen,  both  as  enclosing  rectangles.  The  second  rectangle  may  be 
tilted  through  any  angle  of  rotation.  This  method  is  often  harder  for  users  to  conceptu¬ 
alize  when  compared  with  the  separate  function  method.  It  also  does  not  generalize 
well  to  a  three  dimensional  system. 

GPAC  provides  routines  to  save  and  restore  the  current  transformation  matrix.  This  is 
particularly  useful  when  displaying  hierarchically  nested  symbols  or  showing  different 
sections  of  a  large  picture.  The  current  transformation  matrix  is  pushed  onto  an  inter¬ 
nal  GPAC  stack  when  saved,  and  popped  off  when  restored.  In  a  system  in  which  the 
programming  language  has  been  modified  to  include  graphics  features,  the  user  would 
not  have  to  worry  about  this  at  all.  For  example,  the  LOGO  [Newman  73A]  construct 

IN  100  100  500  500  45  DRAW  BOX 

win  cause  a  box,  created  by  the  display  procedure  BOX,  to  be  drawn  in  the  rectangle 
with  corners  (100,  100)  and  (500,  500)  and  then  rotated  by  45  degrees.  The  language 
constructs  IN  and  DRAW  would  arrange  to  have  the  current  transformation  matrix 
saved  and  a  new  transformation  concatenated  to  it  before  BOX  is  called,  and  the  matrix 
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restored  upon  return.  To  achieve  similar  results  in  GPAC,  the  sequence  of  calls 
PUSHMATO; 

VIEWP0RT(100.,  100.,  500.,  500.); 

R0TATE(45.); 

B0X(); 

POPMATO; 

would  have  to  be  used.  The  GPAC  format  might  be  more  tedious  and  error-prone  for 
some  people.  GPAC  does  not  implement  hierarchically  defined  windows  and  viewports 
by  using  polygon  clipping,  therefore  the  image  produced  by  the  above  example  may 
not  be  the  same  as  the  one  produced  by  a  LOGO  implementation. 

GPAC  includes  two  routines  which  are  used  to  define  the  window  in  user  coordinate 
space  and  the  viewport  in  screen  coordinate  space.  After  the  graphical  information 
provided  by  the  user  has  been  transformed  by  the  current  transformation  matrix,  the 
resulting  transformed  picture  is  clipped  against  the  window,  which  is  a  rectangle 
defined  in  the  user’s  coordinate  space.  Any  part  of  lines,  characters,  and  areas  outside 
the  window  are  not  displayed  on  the  screen.  The  remaining  graphical  information  is 
then  transformed  into  the  actual  screen  coordinates  so  that  all  information  inside  the 
window  appears  inside  the  viewport— a  rectangle  defined  in  the  coordinate  system  of 
the  display. 

GPAC  defines  its  viewports  in  the  actual  coordinates  of  the  device  being  used.  In  order 
to  write  device-independent  programs,  GPAC  will  inform  the  user  of  the  viewport  max¬ 
ima  for  the  device  currently  being  used.  The  largest  square  that  can  be  centered  on 
the  display  screen  is  used  as  its  default  viewport.  Some  graphics  systems  have  users 
specify  viewports  in  some  device-independent  fashion.  For  example,  Omnigraph 
[SprouU  74]  uses  a  normal  viewport  coordinate  system  in  which,  for  each  device,  a  unit 
square  is  defined  to  be  the  largest  square  that  will  fit  on  the  screen  with  its  lower  left 
corner  coinciding  with  that  of  the  screen.  This  method  has  the  advantage  of  being  very 
device-independent,  but  has  the  disadvantage  of  forcing  on  the  user  an  unnatural  coor¬ 
dinate  system.  When  users  know  they  have  a  screen  1024  by  780  rasters,  it  is  difficult 
to  perceive  this  as  1.311  by  1.0. 


3. 1.1. 3.  Segment  Handling 

To  allow  a  user  to  structure  a  complicated  picture  on  the  screen,  GPAC  allows  him  to 
define  the  total  picture  as  a  set  of  picture  segments  which  can  be  manipulated 
independently.  It  is  left  to  the  user  to  decide  how  to  best  divide  his  pictures  into  logi¬ 
cal  units.  To  create  or  redefine  a  segment,  one  must  use  a  routine  to  open  the  seg¬ 
ment.  By  calling  an  “append”  routine,  graphical  primitives  can  be  added  to  the  end  of 
an  existing  segment.  A  segment  is  identified  by  giving  it  a  segment  name  which  is  a 
positive  integer  in  GPAC.  Once  a  segment  has  been  opened,  information  specified  by  all 
subsequent  calls  to  graphical  primitives  will  be  added  to  the  open  segment.  When  the 
segment  has  been  completely  specified,  it  must  then  be  closed. 

Once  a  segment  has  been  created,  it  does  not  immediately  become  visible.  It  remains 
invisible  until  the  GPAC  routine  to  post  it  is  called.  At  a  later  time  the  segment  can  be 
unposted  and  become  invisible.  Unposted  segments  are  not  destroyed  and  can  be 
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posted  again  at  any  time.  The  "post”  and  "unpost”  routines  are  particularly  useful  in 
interactive  applications  using  menus  and  light  buttons. 

GPAC  has  a  routine  to  delete  any  specified  segment  and  one  to  delete  all  existing  seg¬ 
ments.  There  is  also  a  routine  to  unpost  all  existing  segments. 

When  a  portion  of  the  picture  is  deleted  on  a  storage  tube  device,  the  entire  screen 
must  be  erased  and  the  remaining  picture  redra>vn.  When  the  picture  is  modified  on 
raster  scan  devices,  the  entire  picture  must  be  scan  converted  again.  Both  processes 
are  time  consuming.  Thus,  to  minimize  the  number  of  screen  erasures  or  scan  conver¬ 
sions,  GPAC  asks  the  user  to  identify  synchronization  points  in  his  program.  These  are 
the  points  at  which  the  picture  currently  visible  on  the  screen  must  accurately  show 
the  changes  made  by  his  program.  In  an  interactive  program,  synchronization  points 
are  usually  needed  before  requesting  user  inputs.  A  synchronization  point  is  indicated 
by  a  call  to  GPAC’s  "update"  routine.  Thus  on  storage  tube  and  raster  scan  devices  the 
"update”  routine  is  the  only  one  that  modifies  the  screen.  Other  segment  handling 
routines  that  cause  segments  to  be  created,  posted,  or  deleted  do  not  cause  the  screen 
to  change  but  just  record  the  user  request  so  that  "update”  can  act  on  them  when 
next  called.  On  refresh  displays,  screen  updates  are  not  time  consuming  and  so  are 
performed  immediately  upon  user  request,  and  the  "update”  routine  is  ignored. 

An  alternative  updating  strategy  for  storage  tube  displays  would  have  been  to  draw  a 
cross  through  segments  when  they  are  deleted  or  unposted,  without  erasing  the 
screen.  This  will  allow  the  screen  to  be  updated  as  the  user  program  gives  the  com¬ 
mands,  but  an  update  mechanism  is  still  needed  for  specifying  when  the  screen  must 
be  cleared  and  redrawn.  The  effect  this  method  would  have  on  user  interactions  would 
vary  depending  on  the  picture  being  drawn. 

Each  graphical  object  created  by  the  user  is  assigned  a  depth  by  the  GPAC  "depth” 
routine.  If,  when  the  screen  is  updated,  two  distinct  objects  appear  at  the  same  posi¬ 
tion,  the  graphical  object  with  the  smallest  depth  is  displayed.  If  two  segments  have  the 
same  depth,  the  one  with  the  smallest  segment  number  is  visible.  Within  a  segment, 
many  areas  may  be  defined.  Here  depth  decreases  in  the  order  of  creation.  Thus 
areas  added  last  overlap  those  defined  earlier. 

Newman  and  Sproull  [Newman  74]  have  termed  the  graphic  system  organization  used 
by  GPAC  as  a  segmented  transformed  display  file  as  shown  in  Figure  1.  To  make 
changes  to  a  part  of  the  picture,  the  user  must  delete  and  then  recreate  the  appropri¬ 
ate  segments. 

An  alternative  system  organization,  shown  in  Figure  2,  is  one  which  includes  a  struc¬ 
tured  picture  definition  -  a  separate  structure  which  models  the  picture.  An  output 
process  is  added  which  makes  sure  that  changes  in  the  structure  are  immediately  visi¬ 
ble  on  the  screen.  User  routines  are  designed  to  create  and  modify  the  structured  pic¬ 
ture  definition.  The  advantages  of  this  organization  are  that  it  is  very  easy  to  change 
the  picture  and  any  hierarchic  structure  of  the  pictures  can  be  modeled  explicitly  in 
the  data  structure.  Unless  a  very  powerful  display  processor  is  available,  however, 
space  is  needed  for  both  a  transformed  display  file  and  a  structured  picture  definition. 
Furthermore,  a  software  process  to  trace  the  structured  picture  definition  to  create 
the  transformed  display  file  will  also  be  needed.  Unless  this  tracing  process  is  per¬ 
formed  every  time  the  user  changes  the  structured  picture  definition,  which  is 
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inefficient  if  multiple  changes  are  made  to  create  a  single  effect,  the  contents  of  the 
data  structure  are  not  directly  reflected  on  the  display  screen.  The  only  way  to  know 
when  to  perform  the  trace  is  to  have  the  user  signal  when  it  should  be  performed.  This 
complicates  his  view  of  the  system. 

Hence  GPAC’s  organization  does  not  include  a  structured  picture  definition,  but  its  out¬ 
put  routines  pass  their  information  immediately  through  the  transformation  routines 
and  then  deposit  the  results  in  the  transformed  display  file. 


3. 1.1.4.  Film  Routines 

The  film  routines  allow  the  user  to  define  a  film  and  save  it  on  disk  in  a  format  that  can 
be  played  back  at  normal  film  speeds  or  plotted  on  the  Calcomp  Microfilm  plotter. 
These  routines  are  designed  to  be  simple  and  low-level.  Users  can  budd  upon  them 
more  complicated  agenda-based  euiimation  systems.  For  simple  images,  GPAC  can  pro¬ 
duce  new  frames  at  the  normal  film  speed  of  24  frames  per  second,  but  for  complex 
images  it  cannot  keep  up.  Thus,  to  satisfy  the  real-time  goal,  the  frames  are  written  on 
a  disk  file,  and  then  read  back  at  an  appropriate  speed  and  put  on  the  screen  by  a  spe¬ 
cial  purpose  “playback”  program  (See  3.2). 

There  are  four  GPAC  film  routines.  One  is  used  to  signify  the  start  of  film  creation  and 
the  name  of  the  file  to  store  it  in;  another  is  used  to  signal  the  end  of  film  creation. 
The  user’s  view  of  a  film  is  a  numbered  sequence  of  frames,  each  frame  consisting  of 
one  or  more  of  his  segments.  Segments  are  inserted  into  a  frame  with  the  “include” 
routine.  Frames  are  duplicated  with  the  “frame”  routine. 


3. 1.2.  Input 


3. 1.2. 1.  Events 

The  entire  input  mechanism  is  based  around  the  concept  of  an  event.  In  many  interac¬ 
tive  programs  it  is  not  always  possible  to  predict  what  interaction  the  user  will  take 
next.  He  may  type  at  the  keyboard,  point  at  something,  ink  a  stroke  using  the  tablet 
cursor,  or  hit  one  of  the  buttons.  Routines  which  read  the  status  of  a  button,  let  the 
user  do  inking,  or  read  the  keyboard  can  only  be  used  when  the  program  knows  what 
its  user  is  going  to  do  next.  The  event  routines  of  GPAC  act  as  a  monitor  watching  all 
devices  with  which  the  user  can  interact.  When  an  interaction  does  take  place,  they 
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inform  the  user  program  what  happened. 

The  "getevent”  routine  of  GPAC  waits  for  the  next  event  to  happen  and  then  returns  to 
the  user  a  structure  describing  the  event.  The  list  of  possible  events  is: 

Z— axis— down 
Z-eixis— up 
Button— 1-doYm 
Button— 1-up 
Button— 2— down 
Button— 2— up 
Button- 3— down 
Button-3-up 
Inking 

Out-of-range 
In— range 
Tty 

Interval-#! 

Interval-#2 

Interval-#3 

Timeout 

The  first  eight  events  are  caused  when  the  user  presses  or  releases  one  of  the  four  but¬ 
tons,  including  the  Z  axis  button.  The  inking  event  is  a  special  event  handled  in 
software  by  GPAC  and  the  operating  system  (See  3. 1.2.2).  The  range  events  are  caused 
when  the  stylus  leaves  or  enters  the  active  area  of  the  tablet.  The  tty  event  occurs 
when  the  user  types  at  his  keyboard.  Three  interval  timers  are  available  to  generate 
events.  Each  can  be  given  an  interval  duration  and  events  will  be  generated  internally 
by  GPAC  at  each  interval.  The  timeout  event  is  also  given  a  duration.  If  no  other  type 
of  event  has  been  generated  after  the  specified  duration  from  the  time  of  a  call  to 
“getevent”  a  timeout  event  is  generated.  This  enables  user  programs  to  respond 
appropriately  to  a  user  who  is  too  confused  to  do  anything. 

Individual  users  often  do  not  need  such  a  wide  range  of  event  types.  Some  programs 
will  never  use  the  keyboard;  others  may  never  use  the  interval  timers.  Therefore  GPAC 
provides  routines  to  activate  and  deactivate  events.  A  certain  type  of  event  cannot  be 
generated  unless  it  is  activated.  Users  are  allowed  to  activate  and  deactivate  events 
arbitrarily  throughout  their  program.  For  example,  a  program  can  activate  button  2 
only  in  program  states  where  it  makes  sense  for  the  user  to  interact  with  button  2,  and 
deactivate  it  elsewhere. 

Mainly  for  implementation  reasons  (See  4.1.7),  there  is  no  queue  to  collect  input 
events.  The  event  gathering  mechanism  is  “armed"  when  getevent  is  called;  only  then 
can  events  be  generated,  and  only  one  is  processed  at  a  time.  Users  cannot  interact 
ahead  of  the  program.  In  some  cases  this  is  a  good  feature  because  it  prevents  serious 
interaction  errors  (e.g.,  assuming  the  currently  executing  command  will  work  and  giv¬ 
ing  the  next  command,  only  to  find  out  that  the  first  has  failed  and  no  longer  having 
any  means  of  stopping  the  second).  Interactive  systems  should  provide  user  feedback 
for  all  commands.  On  the  other  hand,  a  user  may  wish  to  point  at  several  pictures  on 
the  screen  to  have  his  program  delete  them.  A  queue  of  events  would  allow  the  user  to 
point  at  the  pictures  all  at  once  rather  than  waiting  for  his  program  to  delete  each 
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picture  one  at  a  time.  In  applications  implemented  to  date,  users  have  not  foimd  the 
lack  of  an  event  queue  a  significant  restriction. 

The  structure  returned  by  the  “getevent"  routine  contains  the  type  of  the  event,  the  x 
and  y  positions  of  the  stylus  when  the  event  occurred,  and  the  state  of  all  the  buttons 
(depressed  or  not).  For  an  inking  event  there  is  one  other  field  which  points  to  further 
structures  containing  the  x-y  coordinates  of  all  the  points  in  the  drawn  curves. 


3. 1.2.2.  Inking 

The  inking  event  is  a  special  event  implemented  in  software  to  allow  a  user  to  use  the 
tablet  stylus  to  draw  curves  on  the  screen.  GPAC  implements  three  modes  of  inking: 
equal-space,  equal-time,  and  point.  In  equal-space  and  equal-time  modes,  points  are 
added  to  the  current  curve  as  the  stylus  is  moved  around  the  tablet  surface.  Lines  are 
drawn  joining  the  points  together.  In  equal-space  mode,  a  new  point  is  only  added  to 
the  curve  when  the  distance  between  it  and  the  last  is  greater  than  a  user  supplied 
value.  In  equal-time  mode,  new  points  are  added  to  the  curve  at  a  fixed  time  interval 
specified  by  the  user.  Thus  equal-time  mode  will  reflect  the  dynamics  of  the  user’s 
strokes.  Point  mode  is  often  referred  to  as  rubber-banding.  The  user  specifies  where 
to  place  a  point  and  then  sees  a  moving  line  joining  this  point  to  the  current  stylus 
position  until  he  accepts  a  position  for  the  next  point  to  be  recorded.  Once  this  hap¬ 
pens  the  line  becomes  permanent  and  a  new  line  starts  to  follow  the  stylus  from  this 
new  point.  The  inking  mode  and  parameters  are  specified  in  a  call  to  an  “inkparms” 
routine  of  GPAC. 

To  commence  inking  when  “getevent”  is  called,  the  user  has  to  perform  some  interac¬ 
tion  which  will  not  be  confused  as  one  of  the  other  events.  Since  we  had  used  all  possi¬ 
ble  states  of  the  tablet  in  the  events  described  above,  we  decided  that  the  inking  and 
button-3-down  events  could  not  be  activated  at  the  same  time.  When  inking  has  been 
activated  by  the  “activate”  routine,  pushing  button  3  indicates  an  inking  event  and 
prepares  the  system  to  accept  inked  curves.  Through  the  use  of  the  other  3  buttons  on 
the  stylus  the  user  can  draw  multiple  strokes  in  one  inking  event,  cause  the  first  point 
of  one  stroke  to  coincide  exactly  with  the  last  of  the  preceeding  stroke,  and  erase  all 
strokes  drawn  during  the  current  event  and  restart.  Once  the  user  has  drawn  all  the 
curves  he  wants  during  the  current  event,  he  must  terminate  inking  which  causes 
“getevent”  to  return.  GPAC  allows  this  to  happen  with  either  button  3,  timeout,  or  out 
of  range.  If  the  termination  condition  is  button  3,  hitting  button  3  while  inking  will  ter¬ 
minate  the  event.  If  timeout  is  used,  inking  will  end  when  the  user  has  not  drawn  a 
stroke  during  a  fixed  time  interval.  If  out  of  range  is  used,  moving  the  cursor  out  of 
range  will  terminate  inking.  The  termination  condition  is  also  set  in  the  call  to  “ink¬ 
parms”. 


3. 1.2. 3.  Tracking  and  Cursors 

When  interacting  with  a  tablet,  a  user  should  be  given  visual  feedback  as  to  what  posi¬ 
tion  on  the  display  screen  corresponds  to  the  current  position  of  the  tablet  stylus.  This 
feedback,  called  a  tracking  cross,  moves  about  the  screen  as  the  stylus  is  moved  about 
the  tablet’s  surface.  GPAC  will  use  as  a  tracking  cross  any  picture  segment  the  user 
has  defined.  User  programs  can  call  the  “track”  routine  to  switch  tracking  crosses  at 
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any  time  or  can  call  "untrack'’  to  cause  no  segment  to  be  tracked. 

When  a  user  program  does  a  "getevent"  call,  its  execution  is  suspended  and  a  "gnome” 
deep  within  UNIX  begins  to  watch  for  events  which  have  been  activated.  When  it  sees 
an  event,  it  wakes  up  the  user  program  and  gives  it  the  event  information.  Suspended 
programs  in  a  timesharing  environment  have  very  low  priority  and  usually  are  swapped 
out  onto  the  swapping  disk.  Thus  when  the  gnome  recognizes  a  valid  event,  it  must 
often  swap  in  the  user  program  before  reporting  the  event.  This  may  take  a  fedr 
amount  of  time,  the  result  being  that  the  user  program  does  not  give  the  user  who 
caused  the  event  any  visual  feedback  until  seconds  after  the  event  has  occured.  GPAC 
users  can  solve  this  problem  by  specifying  a  segment  to  be  tracked  after  the  event  has 
been  recognized  by  the  gnome  but  not  yet  passed  back  to  the  user  program.  Any  seg¬ 
ment  previously  tracked  is  unposted.  Thus  user  feedback  is  provided  by  a  tracking 
cross  change. 

Another  user  feedback  problem  occurs  with  the  inking  event  at  two  different  points, 
when  he  first  indicates  that  he  wants  to  ink,  and  when  he  terminates  inking  and  the 
user  program  is  about  to  be  informed  of  the  inking  event.  The  latter  problem  is  the 
same  as  the  one  discussed  above;  the  user  can  provide  feedback  for  the  first  by  speci¬ 
fying  a  different  segment  to  track  whenever  inking  is  in  progress.  Thus  while  in  an  ink¬ 
ing  state,  he  has  a  different  tracking  cross  constantly  reminding  him  of  this  fact. 

Users  usually  track  segments  that  represent  the  state  of  the  system  iconically.  For 
example,  a  cross  may  be  tracked  when  in  normal  mode,  a  pen  when  inking,  and  a  bud- 
dha  (signifying  patience)  while  the  event  is  being  passed  back  to  the  user  program. 


3.1.2. 4:.  Other  Input  Routines 

Whenever  a  user  program  wants  to  find  out  the  stylus  position  immediately  without 
waiting  for  the  user  to  press  a  button  or  for  an  interval  timer  to  tick,  the  routine 
"readposition”  can  be  used.  It  reads  the  current  x-y  position  of  the  tablet  and  returns 
to  the  user  immediately.  “Readposition”  is  useful  for  functions  requiring  constant  pol¬ 
ling  of  the  tablet,  but  the  "getevent"  routine  is  better  suited  for  pointing  and  starting¬ 
stopping  functions.  GPAC  also  has  a  directly  callable  inking  routine  which  is  appropri¬ 
ate  when  it  is  already  known  that  the  user  wishes  to  ink.  The  user  then  does  not  have  to 
hit  button  3  to  commence  inking,  as  was  required  to  get  inking  through  "getevent”. 
The  structure  returned  by  both  these  routines  is  similar  to  that  returned  by 
"getevent".  GPAC  also  has  a  "clearink”  routine  to  clear  inked  curves  from  the  screen. 
GPAC  maintains  only  one  ink  buffer  to  store  strokes  from  the  inking  event,  so  a  second 
inking  event  will  destroy  the  strokes  of  the  first.  If  the  user  wishes  them  to  remain  visi¬ 
ble,  he  can  open  a  segment  and  draw  a  permanent  copy  with  the  points  returned  by  the 
event. 

GPAC  includes  a  routine  that  attempts  to  recognize  a  character  or  symbol  drawn  as  an 
inked  curve  or  curves.  The  user  provides  GPAC  with  a  file  of  predefined  descriptions  of 
how  to  draw  each  character.  This  dictionary  file  can  be  created  with  a  separate  char¬ 
acter  recognizer  trainer  program.  The  "recognize"  function  returns,  in  addition  to  the 
character  code  assigned  to  the  recognized  symbol,  the  confidence  level  at  which  the 
symbol  was  recognized  and  the  minimum  enclosing  rectangle  of  the  symbol.  Some  sys¬ 
tems  have  a  character  recognizer  automatically  called  at  every  inking  event,  but  in 
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many  applications  of  inking  the  character  recognizer  is  not  wanted.  In  GPAC  the  user 
must  specifically  request  the  recognizer. 

The  final  input  routine  is  used  to  transform  screen  coordinates  to  user  coordinates. 
This  involves  finding  the  inverses  of  the  window-viewport  transformation  and  the 
current  transformation  and  applying  them  to  the  screen  coordinates  to  get  user  coor¬ 
dinates.  All  x-y  coordinates  returned  by  the  input  routines  are  in  the  screen  coordi¬ 
nate  space  of  the  display  being  used. 


3.1.3.  Miscellaneous  Routines 

The  “init”  routine  of  GPAC  is  used  to  initialize  the  package  by  specif5dng  the  device  on 
which  the  output  is  to  occur,  the  character  font  to  be  used,  the  maiximum  number  of 
segments  desired,  and  the  sizes  of  display  file  and  ink  buffer  needed  by  the  program. 
Dynamic  sizes  were  not  possible  because  of  implementation  considerations  (See  4,1.1). 
Since  having  fixed  sizes  would  be  inefficient  for  many  programs,  the  user  is  asked  to 
provide  this  information.  GPAC  programs  can  be  run  on  four  different  display  termi¬ 
nals:  the  Graphic  Wonder,  the  Colour  Video  system,  the  Tektronix,  and  the  Null  device. 
The  Null  device  is  a  fictitious  device  which  will  cause  GPAC  to  output  all  graphical  infor¬ 
mation  which  would  normally  appear  on  the  screen  into  a  file  in  a  special  standard 
graphics  format  (See  4.2.1).  This  file  can  then  be  used  to  produce  hardcopy  output  on 
the  Versatec  Printer/Plotter  or  the  Calcomp  Microfilm  Plotter.  The  Graphic  Wonder  is 
actually  implemented  as  four  logical  devices,  so  that  up  to  four  totally  independent 
processes  may  be  using  the  screen  at  one  time  (See  4.1.3).  Each  process  is  totally  pro¬ 
tected  from  the  others. 

For  any  given  device  some  of  the  GPAC  input  and  output  routines  cannot  be  performed 
on  the  hardware.  For  example,  colour  setting  and  filling  on  the  Graphic  Wonder,  and 
intensity  settings  and  tracking  on  the  Tektronix.  GPAC  treats  these  as  no  operation 
routines  on  those  particular  devices. 

The  ability  to  send  the  picture  currently  on  the  user's  screen  to  another  display  is  pro¬ 
vided  by  the  “snap”  routine.  Snap’s  major  use  is  to  generate  hardcopy  images  on  the 
Versatec  of  intermediate  states  of  interactive  programs.  The  "snap”  can  also  be  saved 
in  any  file  specified  by  the  user. 

In  many  interactive  programs  there  are  static  portions  of  pictures  which  are  created 
once  during  initialization  and  never  deleted.  Often  significant  amounts  of  program  are 
required  to  create  these  pictures.  In  large  graphics  application  systems  using  multiple 
processes,  there  needs  to  be  some  way  to  transmit  pictures  between  processes.  The 
"interp”  routine  of  GPAC  is  one  means  of  solving  these  problems.  "Interp”  takes  a  file 
containing  normal  GPAC  calls  (e.g.,  “open”,  "post”,  and  “line”)  and  their  arguments  in 
an  encoded  format  and  calls  the  actual  GPAC  routines  to  put  the  images  on  the  screen. 
These  files  are  created  by  a  separate  set  of  routines  available  to  the  user  in  another 
library.  Large  static  pictures  can  be  stored  in  an  interp  file  and  displayed  using 
“interp”.  Pictures  can  be  passed  between  concurrently  executing  processes  using 
interp  files. 
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GPAC  is  quite  diligent  in  checking  for  user  errors.  All  errors  result  in  an  error  message 
on  the  user’s  terminal.  The  error  messages  are  concise  and  meaningful.  However,  the 
user  can  turn  error  messages  off.  He  can  still  determine  when  an  error  has  occurred 
because  all  GPAC  routines  eire  functions  which  return  an  error  condition  if  an  error 
occurs. 

The  reader  is  referred  to  Appendix  A  -  the  GPAC  Users’  Mamual,  for  a  more  detailed 
description  of  GPAC’s  user  interface. 


3.2.  Playback 

The  "playback”  program  is  used  to  show  films  created  using  GPAC’s  film  routines  on 
the  Graphic  Wonder  or  Colour  Video  displays.  It  can  be  run  under  the  control  of 
another  program  or  controlled  by  a  user  with  the  tablet.  In  either  case  playback 
accepts  the  following  commands: 

1)  Starting  Frame  —  the  user  specifies  the  first  frame  he  wishes  to  see 

2)  Ending  Frame  —  the  last  frame  to  be  shown  is  specified 

3)  Frames  per  Second  -  the  speed  of  playback  is  determined 

4)  Frame  Increment  -  this  command  specifies  n  where  every  nth  frame  is 

shown 

5)  Cycle  Flag  -  If  the  cycle  flag  is  turned  on,  playback  will  automatically  return 

to  the  starting  frame  and  start  over  after  the  ending  frame  is  reached. 
If  not  on,  playback  will  stop  when  the  ending  frame  is  encountered 

6)  Frame  Indicator  —  If  the  frame  indicator  is  turned  on,  playback  will  display 

and  continuously  update  a  frame  counter  as  it  plays  back 

7)  Start  -  playback  begins  at  the  starting  frame 

8)  Stop  -  playback  stops  immediately 

9)  Continue  -  playback  continues  from  the  frame  at  which  it  was  stopped 

10)  Quit  -  the  playback  program  is  terminated. 


The  playback  program  is  designed  to  run  in  real-time  with  accurate  timing.  Users  can 
see  if  their  film’s  dynamics  are  correct  without  creating  and  developing  hardcopy  film. 
Since  tablet  support  is  also  real-time,  users  can  be  sketching  further  images  and 
dynamics  at  the  same  time  that  playback  is  displaying  a  film. 
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3.3.  Scroller 


The  scroller  is  a  program  which  echoes  onto  the  Graphic  Wonder  screen  characters 
either  being  typed  at  the  Graphic  Wonder  keyboard  or  being  output  by  programs  run 
from  that  keyboard.  It  too  must  be  a  real-time  program  as  it  must  be  able  to  echo  as 
fast  as  a  user  can  type.  As  the  name  implies,  the  scroller  first  fills  up  its  area  on  the 
screen  with  characters,  and  then  moves  all  lines  up,  deleting  the  top  line,  to  make 
room  for  following  lines.  The  keyboard  is  equipped  with  a  few  specied  keys  in  addition 
to  the  ASCII  character  set  which  were  used  to  allow  a  user  typing  at  the  keyboard  to 
enter  the  following  scroUer  commands; 

1)  Release  -  the  scroller  stops  echoing  characters  and  gives  up  its  portion  of 

the  special  double-port  memory,  making  it  available  to  other  graphics 
programs. 

2)  Acquire  -  scroller  acquires  some  double-port  memory  and  starts  echoing 

characters  again. 

3)  Viewport  —  the  scroller  outputs  its  characters  onto  a  vievrport  on  the  screen. 

With  this  command  the  user  can  change  the  scroller’s  viewport  by 
specifying  in  screen  coordinates  the  top,  bottom,  left,  and  right  coordi¬ 
nates. 

4)  Clear  —  the  scroller  clears  all  characters  from  the  screen  and  starts  echoing 

characters  from  the  top  of  its  viewport. 

5)  Scale  -  this  command  changes  the  scale  at  which  characters  are  output. 

6)  Stop  —  when  large  amounts  of  text  are  being  listed  with  the  scroller,  this 

command  is  used  to  delay  the  output  of  characters  until  the  Go  com¬ 
mand  is  given. 

7)  Go  this  command  causes  the  scroller  to  start  outputting  characters  again 

after  a  STOP  command. 

B)  Page  —  after  a  Stop  command,  Page  causes  the  scroller  to  output  one  page 
of  text  (the  number  of  lines  that  fills  the  scroller’s  viewport),  and  stop 
again. 


The  first  five  commands  mentioned  above  can  also  be  issued  by  programs  run  at  the 
Graphic  Wonder. 


4.  ImpLeTnentation 

This  chapter  deals  with  the  implementation  of  the  user  interface  and  the  levels  of 
software  lying  underneath. 
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The  first,  and  one  of  the  most  important,  implementation  decisions  made  was  to  adopt 
a  partitioning  strategy.  The  user  interface  had  to  be  implemented  as  a  set  of  pro¬ 
cedures  which  are  loaded  with  the  user’s  application  program.  There  also  had  to  be 
device  drivers  added  to  UNIX  to  handle  the  interrupts  and  very  low  level  interfaces  to 
the  hardware.  The  question  was  how  to  partition  the  implementation  between  user 
space  and  system  space  (inside  UNIX).  The  goals  outlined  in  Chapter  1  played  a  large 
role  in  the  decision.  Achieving  real-time  response,  minimizing  the  amount  of  code 
added  to  system  space  (very  critical  since  the  operating  system  is  always  core 
resident),  and  preserving  the  style  of  UNIX  were  all  considered.  In  the  final  design, 
graphical  input  and  output  were  treated  differently. 

The  source  of  most  output  is  the  user’s  application  program,  which  decides  what  the 
pictures  look  like,  where  they  go.  and  when  they  appear  and  disappear.  Thus  it  was 
decided  to  partition  output  functions  so  that  as  many  as  possible  are  in  user  space, 
close  to  their  source.  Costly  system  calls  are  avoided  and  relatively  little  is  added  to 
system  space.  The  system  routines  are  used  to  initialize  and  perform  special  functions 
of  the  hardware,  but  apart  from  that,  the  images  on  the  screen  are  controlled  from 
user  space.  The  alternative  would  be  to  put  some  output  routines  into  the  operating 
system.  In  addition  to  increasing  system  space  size,  this  also  has  the  disadvantage  of 
forcing  the  design  and  implementation  of  these  system  routines  on  all  users. 

Graphical  input,  on  the  other  heind,  originates  with  the  user  pushing  buttons,  typing 
characters,  and  inking.  The  first  level  of  software  to  receive  this  information  is  the 
low-level  interrupt  roufme  of  the  device  driver.  The  destination  of  the  information  is 
the  user  program  as  the  result  of  his  "getevent”,  "readposition”  or  "ink”  call.  Because 
real-time  response  was  considered  of  maximum  importance  here,  most  of  the  input 
routines  are  in  system  space.  The  benefit  of  this  is  that  real-time  response  is 
guaranteed.  This  is  true  because  a  user’s  interactions  can  be  recognized  as  soon  as  an 
interrupt  occurs,  since  it  is  a  high  priority  event  in  the  operating  system.  The  disad¬ 
vantage  is  that  a  fedr  amount  of  code  is  added  to  system  space.  The  alternative  would 
be  to  give  graphics  programs  special  high,  real-time  priority  when  doing  input  and  have 
them  poll  all  the  activated  input  devices  for  events.  Anything  less  than  real-time  would 
be  unacceptable  as  user  interactions  could  be  missed.  Inking  must  be  performed  in 
real-time  or  else  the  result  will  not  reflect  the  user’s  actions.  The  problem  of  providing 
user  programs  the  real-time  capabilities  they  need  in  the  time-sharing  environment  of 
UNIX  is  discussed  in  section  5.2. 

In  summary,  the  partitioning  strategy  was  to  put  as  much  as  possible  of  the  response- 
time-critical  portions  of  graphical  input  in  system  space,  and  as  much  of  the  graphical 
output  in  user  space.  The  following  sections  describe  the  system  and  user  space  imple¬ 
mentations. 


4.1.  System  Space 

This  section  describes  the  needed  additions  and  modifications  to  the  operating  system. 
Two  support  routines,  "grabcore"  and  "maptouser”,  which  are  used  by  most  graphic 
device  drivers  are  first  described.  Then  the  drivers  are  discussed  individually.  Users 
writing  application  programs  do  not  directly  use  the  routines  described  here.  GPAC 
performs  all  interfacing  automatically. 
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4.1.1.  Grabcore 


In  order  to  operate,  some  graphics  devices  in  our  configuration  must  have  access  to 
special  sections  of  memory.  For  example,  both  the  Graphic  Wonder  and  the  Colour 
Video  system  refresh  their  screens  out  of  special  double-port  memory.  This  core  can 
otherwise  be  used  by  UNIX  to  execute  user  programs.  Because  of  a  design  flaw,  the 
Versatec  must  have  its  buffer  of  memory  in  the  lower  32K  of  physical  core. 

When  the  opening  of  a  device  is  requested,  some  of  its  special  memory  must  first  be 
acquired.  One  way  of  assuring  this  would  be  always  to  reserve  it  for  the  device.  This  is 
very  wasteful.  The  devices  are  not  always  in  use,  and  they  may  need  only  part  of  their 
special  memory  even  when  they  are  in  use.  Thus  we  needed  a  routine  which  a  device 
driver  could  call  to  gain  sole  access  to  a  specific  section  of  memory  by  specifying  a 
starting  physical  address  and  a  size. 

The  UNIX  core  allocator  was  not  sufilcient,  as  it  would  not  allocate  memory  at  a  specific 
address.  Hence  a  special  “grabcore”  routine  was  written.  One  of  the  problems 
encountered  was  that  some  UNIX  processes  may  be  executing  in  the  memory 
requested.  “Grabcore”  swaps  these  processes  out  until  the  memory  is  free,  and  then 
removes  the  memory  from  UNIX’s  free  memory  map  so  it  cannot  be  allocated  to  any 
processes.  “Grabcore”  maintains  a  table  of  addresses  and  sizes  of  grabbed  sections  of 
memory.  Upon  encountering  a  process  which  cannot  be  swapped  out  because  it  is  per¬ 
forming  raw  I/O  or  forking,  “grabcore”  will  delay  and  sleep  for  four  seconds  before  try¬ 
ing  again.  “Grabcore”  solves  the  mutual  exclusion  problem  of  two  distinct  processes 
trying  to  grab  the  same  piece  of  core  at  the  same  time  by  using  a  semaphore.  Checks 
are  made  for  possible  deadlock  conditions  before  starting  to  swap  out  processes.  If 
there  exists  a  currently  running  process  which  will  not  fit  in  core  if  the  requested  core 
is  given  to  the  device  driver,  "grabcore”  will  return  an  error  condition.  Otherwise  that 
process  would  remain  swapped  out  until  the  driver  returns  the  core,  possibly  hours 
later. 

A  different  implementation  could  have  used  UNIX's  core  adlocator  to  request  all  of 
memory.  The  grabbing  process  would  then  have  to  wait  until  all  processes  in  the  sys¬ 
tem  were  swapped  out  (on  the  average,  two  to  four  seconds)  before  it  would  obtain  the 
core.  After  taking  the  amount  needed,  it  would  return  the  rest  for  UNIX  to  use.  All  the 
checks  mentioned  above  would  still  have  to  be  done.  The  advantage  of  this  method  is 
that  it  does  not  require  as  much  new  code  in  system  space.  The  major  disadvantage  is 
that  grabbing  will  take  a  relatively  long  time,  particularly  since  processes  not  residing 
in  the  requested  core  would  be  swapped  out. 

Another  routine,  “freegrab”,  was  written  to  return  grabbed  sections  of  memory  to 
UNIX.  Other  routines  which  would  allow  device  drivers  to  shrink  and  expand  grabbed 
areas  were  not  implemented  because  their  use  would  not  have  been  sufficient  to  war¬ 
rant  the  increase  in  system  size. 
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4.1.2.  Maptouser  and  Moveuuindow 


Once  the  device  driver  has  acquired  its  special  memory  with  '’grabcore”,  the  user 
space  portion  of  the  program  must  be  able  to  access  it  to  create  and  modify  the 
display  file.  The  first  access  mechanism  we  implemented  used  read  and  write  system 
calls  to  update  the  display  file.  The  device  driver  treated  the  display  file  as  an  random 
access  file  in  core  which  could  be  read  or  written.  The  address  mapping  to  the  display 
file  and  moving  of  information  was  done  by  the  driver  every  time  a  read  or  write  was 
issued  from  user  space.  This  implementation  was  found  to  be  too  slow  because  it  was 
an  indirect  method--the  information  created  in  user  space  was  copied  down  into  the 
operating  system  and  then  copied  again  through  the  special  address  mapping  into  the 
display  file.  Also,  because  display  files  are  not  often  updated  in  large  contiguous  sec¬ 
tions,  but  usually  in  a  series  of  small  scattered  sections,  multiple  read  and  write  opera¬ 
tions  were  needed  for  each  update.  Therefore,  to  provide  the  user  maximum  access 
speed  to  the  display  file,  it  is  put  directly  into  the  data  space  of  the  user  program.  This 
is  pyossible  because  the  memory  management  hardweire  on  the  11/45  is  capable  of  han¬ 
dling  programs  and  data  not  stored  contiguously  in  core. 

However,  there  is  a  problem  when  large  display  files  are  used.  User  space  programs 
can  only  address  a  total  of  32K  words  and  some  display  files  may  be  larger  than  this. 
This  problem  is  solved  by  having  the  user’s  program  mapped  onto  only  a  sub-section  of 
the  display  file.  This  sub-section  is  called  the  window.  The  size  of  the  window  is  set  by 
the  user  with  a  system  call.  He  can  also  move  the  window,  and  thus  also  the  mapping, 
over  the  display  file.  It  is  hoped  that  the  user  can  maintain  some  locality  of  reference 
so  the  window  does  not  have  to  be  moved  often.  On  the  Graphic  Wonder,  the  display  file 
is  usually  small  enough  so  that  the  window  can  be  the  same  size  as  the  display  file.  The 
display  file  mapping  is  shown  in  Figure  3. 

The  implementation  of  the  "maptouser”  routine  required  more  changes  to  UNIX  than 
did  any  other  graphics  routine.  Modifications  had  to  be  made  to  the  user  address  map¬ 
ping  routines,  the  swapping  routine— since  we  do  not  want  to  swap  the  display  file,  the 
raw  I/O  routines,  the  program  loader,  the  forking  routines,  and  the  core  image  dump¬ 
ing  routine.  These  changes  were  not  large  but  their  number  was  disturbing. 

If  a  process  is  mapped  into  a  display  file  and  then  “forks”,  the  new  child  process 
receives  the  same  mapping.  If  a  process  “execs”  when  mapped  to  a  display  file,  the 
mapping  is  not  retained  but  it  can  easily  ask  to  be  mapped  again.  The  display  file  is 
not  lost  in  the  meantime,  because  the  process  still  has  the  device  open.  A  routine 
“unmaptouser”  is  used  to  undo  the  mapping  of  a  process  to  a  display  file  when  it  is 
finished  with  the  device.  With  these  routines  it  is  possible  to  have  multiple  processes 
all  mapped  into  the  same  display  file.  The  processes  are  responsible  for  their  own  syn¬ 
chronization  (  See  4.1.3). 


4.1.3.  Graphic  Wonder  Driver 

The  Graphic  Wonder  driver  controls  the  low-level  hardware  and  operating  system 
dependent  features  of  the  Graphic  Wonder.  It  allows  a  user  program  to  acquire  a 
display  file  and  to  control  the  window  mapping  the  display  file  into  the  program  s 
address  space.  Both  the  size  of  the  display  file  and  the  window  are  specified  by  the 
user.  The  driver  takes  care  to  grab  the  piece  of  special  double-port  core  which  will 
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leave  the  remaining  core  as  contiguous  as  possible,  since  UNIX  must  load  programs 
contiguously.  The  driver  also  allows  user  programs  to: 

1.  start  the  display  at  an  address  in  the  display  file 

2.  halt  the  display  immediately 

3.  find  out  the  current  state  of  the  display 

4.  set  various  format,  scale  and  speed  registers  of  the  device. 

The  driver  edso  processes  interrupts  from  the  Graphic  Wonder.  ITie  driver  handles  the 
following  types  of  interrupts,  caused  by  interrupt  instructions  placed  in  the  display  file 
by  the  user: 

1)  Sync  -  The  Graphic  Wonder  should  execute  a  cycle  through  its  display  file 

every  sixtieth  of  a  second.  The  sync  interrupt  tells  the  driver  the  cycle 
is  finished  and  to  start  the  next  one  at  the  next  sixtieth  of  a  second. 
Without  a  sync  interrupt  in  its  refresh  cycle  the  display  would  be  very 
bright  for  images  with  few  lines  and  dim  for  complicated  images,  since 
the  cycle  is  much  shorter  and  can  therefore  be  executed  more  often. 
If  it  takes  longer  than  a  sixtieth  of  a  second  to  execute  a  cycle,  the 
driver  restarts  the  display  immediately  after  the  cycle  is  complete. 

2)  Waittil  -  This  interrupt  is  used  for  display  file  manipulation  when  it  is  critical 

to  know  where  the  Graphic  Wonder  processor  is  executing.  GPAC  uses 
this  interrupt  when  deleting  segments  to  prevent  the  display  from  run¬ 
ning  wild  (  See  4.2. 4.4). 

3)  Load  State  registers  -  Special  registers  of  the  display  not  changeable  by 

display  instructions  can  be  set  by  this  type  of  interrupt. 


The  ability  to  share  the  Graphic  Wonder  among  several  processes  has  increased  its  pro¬ 
ductivity  greatly.  A  user’s  GPAC  program  need  not  worry  about  echoing  characters 
typed  at  the  keyboard,  because  the  scroller  can  do  it  while  running  as  a  totally 
independent  process.  Multiple  processes  working  together  to  solve  a  problem  can  all 
display  their  results  graphically  to  give  a  total  solution.  Most  important  of  all,  a  pro¬ 
cess  can  use  the  screen  without  knowing  anything  about  other  processes  also  using  the 
same  screen.  This  enables  us  to  write  modular  programs  (e.g.,  the  scroller  and  play¬ 
back  programs)  which  can  be  used  in  building  larger  systems  without  making  any 
modifications. 

Although  the  “maptouser”  routine  enables  a  process  and  all  its  descendants  to  share 
the  same  display  file,  this  feature  can  only  be  used  if  the  processes  cooperate  with 
each  other.  They  have  to  share  memory  allocation  tables  to  ensure  they  do  not  try  to 
use  the  same  parts  of  the  display  file.  A  malicious  process  could  easily  destroy  another 
display  file  because  it  has  unlimited  access  to  it.  Even  a  bad  display  file  created  errone¬ 
ously  by  one  process  would  cause  all  the  images  of  the  other  processes  to  be  lost.  With 
this  method  only  processes  in  the  same  family  tree  could  use  graphics  at  the  same 
time.  This  was  not  general  enough  for  our  purposes. 
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What  we  really  want  is  to  time-sheLre  the  device  in  much  the  same  way  the  CPU  is  time- 
shared  by  UNIX.  A  table  of  processes  using  the  device  is  kept.  A  scheduling  algorithm 
is  used  to  decide  which  display  file  to  display  next.  Independent  processes  can  open 
the  device,  obtain  their  own  display  file,  and  have  it  mapped  to  them.  The  Graphic 
Wonder  has  relocation  hardware,  so  that  every  time  the  scheduler  switches  display 
files,  the  relocation  of  the  display  is  changed.  This  means  each  user  can  treat  his 
display  file  as  if  he  had  a  Graphic  Wonder  all  to  himself.  In  addition  to  relocation,  the 
state  of  the  device  is  reset  when  a  new  display  file  is  started,  and  saved  when  it  is 
stopped. 

In  a  time-sharing  system,  a  scheduler,  usually  controlled  by  a  clock,  interrupts 
processes  after  their  alloted  time  slice  and  starts  another  process.  A  graphics  process 
(i.e.,  a  display  file)  should  stop  itself  by  executing  a  Sync  interrupt.  Whenever  the 
driver  receives  a  Sync,  it  saves  the  state  and  switches  to  the  next  display  file  that  has 
not  been  run  in  the  current  sixtieth  of  a  second.  If  no  such  process  exists,  the  driver 
waits  till  the  sixtieth  of  a  second  passes  (performing  a  real  Sync),  before  starting  the 
first  process  again.  There  is  still  the  danger  of  a  graphics  process  getting  the  Graphic 
Wonder  into  an  infinite  loop  and  never  doing  a  Sync  interrupt.  This  is  regarded  as  an 
error  by  the  driver,  which  has  a  protection  mechanism  that  kills  a  runaway  graphics 
process  that  has  not  executed  a  Sync  interrupt  within  one  sixth  of  a  second.  Other 
graphics  processes  are  not  affected. 

The  Graphic  Wonder  driver  provides  the  users  with  several  logical  Graphic  Wonders  on 
one  physical  device.  It  is  trivial  to  extend  this  to  a  two-tube  configuration  in  which 
there  are  two  display  screens  but  most  of  the  remaining  hardware  shared  (an  option 
available  from  Three  Rivers). 


4.1.4.  Coloxcr  Video  Driver 

The  current  hardware  on  the  Colour  Video  display  makes  its  driver  quite  trivial.  User 
programs  are  allowed  to  open  the  device  and  then  be  mapped  into  a  colour  video 
display  file.  The  size  of  the  display  file  and  the  user’s  window  onto  it  are  parameters. 
Only  one  process  is  allowed  to  open  the  Colour  Video  at  a  time.  All  of  its  children  can 
still  be  mapped  to  the  display  file  using  "maptouser”.  Totally  independent  processes 
cannot  access  the  Colour  Video  at  the  same  time. 

The  Colour  Video  has  no  state  and  control  registers  (just  an  on-off  switch  on  front),  so 
no  other  functions  need  to  be  performed.  In  the  future  it  will  have  to  handle  a  pro¬ 
grammable  colour  map  and  a  more  sophisticated  display  processor. 


4.1.5.  Versatec  Driver 

The  Versatec  Printer-Plotter  requires  a  buffer  in  core  memory  in  which  the  user  places 
characters  to  be  printed  or  a  bit  matrix  of  a  scan-converted  picture.  This  buffer  must 
be  located  in  the  first  32K  of  memory.  When  a  user  program  requests  the  Versatec,  it 
is  given  a  display  file  in  the  correct  portion  of  core  and  mapped  to  it  by  the  Versatec 
driver.  When  the  user  has  filled  the  buffer  with  information,  he  does  a  system  call  to 
the  driver  specifying  whether  it  is  print  or  plot  information  and  how  much  of  the  buffer 
is  used.  The  driver  starts  the  hardware  and  then  allows  the  user  process  to  continue. 
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The  user  process  can  be  forming  the  next  buffer  while  the  hardware  processes  the 
current  one.  It  will  not  perform  a  new  command  from  the  user  until  it  receives  an 
interrupt  specifying  that  the  hardware  has  received  the  current  buffer’s  information. 
The  driver  also  handles  other  commands  performing  variable  size  form  feeds. 


4.1.6.  Graphic  Wonder  Keyboard  Driver 

The  Graphic  Wonder  keyboard  driver  handles  interrupts  generated  by  characters  typed 
at  that  device.  A  character  is  first  translated  via  table  lookup  from  the  device’s  code 
into  ASCII,  and  then  passed  on  deeper  into  UNIX  to  be  queued  for  reading  by  user  pro¬ 
grams.  At  the  same  time  the  driver  places  the  translated  character  onto  a  queue  of  a 
pseudo  device  which  the  scroller  reads  to  echo  characters  onto  the  Graphic  Wonder 
screen.  The  special  "Meta”  key  on  the  keyboard  causes  all  characters  typed  while  it  is 
depressed  to  be  put  only  on  the  pseudo  device’s  queue.  In  this  way  the  scroller  com¬ 
mands  described  in  Chapter  3  are  only  sent  to  the  scroller,  and  not  to  user  programs, 
such  as  the  "shell”  or  "editor",  which  may  also  be  reading  the  keyboard. 


4.1.7.  Tablet  Driver 

The  tablet  driver  implements  the  response-time-critical  graphical  input  routines 
described  in  the  user  interfaces  presented  in  Chapter  3.  The  driver  accepts  five  basic 
commands: 

1)  Track  —  User  specifies  where  in  his  display  file  to  keep  a  copy  of  the  current 

x-y  position  of  the  stylus 

2)  Untrack  —  Tracking  is  to  be  terminated 

3)  Activate  -  User  can  specify  which  events  to  activate  and  with  which  parame¬ 

ters 

4)  Deactivate  —  Events  are  deactivated  with  this  call 

5)  Getevent  —  User  program  requests  an  event. 


The  tracking  function  and  the  inking  event  are  the  only  portions  of  the  system  input 
support  that  communicate  directly  with  the  user’s  display  file,  bypassing  the  user  pro¬ 
gram.  The  user  informs  the  tablet  driver  of  the  location  in  his  display  file  of  the  seg¬ 
ment  to  be  tracked  and  the  ink  buffer  to  be  used  for  mking.  The  driver  uses  special 
address  mapping  to  access  these  display  file  areas  quickly  when  it  receives  new  infor¬ 
mation. 

The  tablet  driver  receives  interrupts  at  fixed  intervals.  The  interrupt  routine  is  respon¬ 
sible  for  updating  the  tracking  location  in  the  user’s  display  file  and  for  identifying  and 
reporting  activated  events.  If  inking  is  started  the  driver  no  longer  looks  for  events, 
but  decodes  the  interactions  happening  at  the  tablet  into  strokes  which  are  displayed 
on  the  screen.  The  decoding  is  a  complicated  process  governed  by  the  inking  mode 
and  its  parameters,  the  inking  termination  condition,  the  current  state  of  inking,  and 
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the  current  x-y  position.  When  the  driver  recognizes  the  termination  condition  an 
event  is  generated  and  the  user  program  continues  executing. 

The  interval  event  and  timeout  event  and  equal-time  inking  mode  are  implemented 
using  a  programmable  real  time  clock.  The  tty  event  (keyboard)  is  implemented  by 
periodically  polling  the  user’s  keyboard  input  queue. 

There  is  no  fundamental  reason  that  forbade  the  implementation  of  a  queue  to  accu¬ 
mulate  events.  However,  the  extra  code  required  would  add  substantially  to  an  already 
large  driver.  It  would  also  be  quite  difficult  to  implement  a  queue  containing  inking 
events,  since  it  would  require  a  more  complicated  multiple  ink  buffer  orgemization  of 
the  display  file. 


4.1.8.  Real-Time  Res-ponse 

One  of  the  goals  of  this  project  was  to  provide  real-time  response  to  graphics  pro¬ 
grams.  Response  is  very  good  when  the  system  is  being  lightly  used,  but  it  degrades 
sharply  when  swapping  occurs.  As  soon  as  a  process  is  swapped,  it  cannot  be 
guaranteed  real-time  response.  Two  solutions  have  been  tried  to  provide  real-time 
response.  The  first  is  the  tablet  driver  in  which  the  real-time-critical  portion  of  the 
systems  input  routines  have  been  placed  right  in  the  tablet’s  interrupt  routine.  This 
has  provided  excellent  response  even  on  a  heavily  loaded  system.  The  disadvantage 
with  this  solution  is  that  it  is  very  specialized  for  the  tablet.  A  general  solution  involv¬ 
ing  fairly  major  changes  to  the  UNIX  scheduler  was  attempted.  User  programs  would 
request  a  real-time  status  which  would  ensure  that  they  would  be  swapped  out  only  if 
absolutely  necessary  euid  that  they  could  have  almost  infinite  time-slices  in  which  to 
execute.  This  solution  has  been  temporarily  abandoned  because  of  insufficient  time  to 
debug  the  implementation.  The  author  believes  that  this  is  the  more  desirable  solution 
and  will  pursue  it  in  the  future. 

This  completes  the  description  of  the  system  softwaire  of  the  graphics  system.  As  with 
the  rest  of  the  UNIX  operating  system,  the  reader  is  referred  to  the  system  documen¬ 
tation  and  the  code  itself  for  a  more  detailed  view. 


4.2.  User  Space 

This  section  describes  the  portions  of  the  graphics  system  implemented  in  user  space. 
These  routines  do  not  need  to  be  in  system  space,  because  they  do  not  need  the  special 
privileges  of  system  routines  or  because  they  are  not  critical  for  real-time  response. 


4.2.1.  Standard  Format 

As  the  graphics  system  grew  and  more  display  devices  were  added  and  supported,  it 
became  apparent  that  a  device-independent  standard  graphics  format  was  needed. 
Device-independence  was  important  because  programs  written  to  generate  or  manipu¬ 
late  standard  format  pictures  would  then  be  able  to  direct  their  output  to  any  device. 
It  needed  to  be  general-purpose  to  meet  all  users’  needs,  and  it  needed  to  be  standard¬ 
ized  so  that  every  user  would  use  it  instead  of  each  inventing  his  own. 
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There  are  three  types  of  programs  which  deal  with  st2mdard  format:  “sources”, 
“filters”,  and  “sinks".  Sources  are  prograims  that  take  picture  information  and  pro¬ 
duce  a  standard  format  representation.  Any  program  using  the  Null  device  in  GPAC  is 
a  source.  A  sketch  editor  is  a  source  when  it  stores  user  pictures  in  standard  format. 
A  filter  is  a  program  that  takes  standard  format  as  input,  performs  some  transforma¬ 
tion,  deletion,  or  addition  to  the  picture  and  then  outputs  a  standard  format  represen¬ 
tation  of  the  result.  Examples  of  filters  are  a  program  to  scale,  rotate  and  translate 
standard  format  pictures,  and  a  progreim  to  expand  characters  in  standard  format  to 
their  line  drawing  equivalent  according  to  a  user  specified  font  file.  Sinks  are  pro¬ 
grams  which  take  standard  format  as  input  and  produce  the  pictures  represented 
therein  on  a  particular  graphics  device.  A  sink  can  ignore  any  command  it  cannot  per¬ 
form  on  its  device  (e.g.,  colour  on  the  Graphic  Wonder  or  intensity  on  the  Tektronix). 
Examples  of  sinks  are  programs  taking  standard  format  as  input  and  displaying  it  on 
the  Graphic  Wonder,  Tektronix,  Colour  Video,  Versatec,  and  Calcomp  Microfilm  Plotter 
devices. 

Standard  format  is  currently  being  used  for  three  major  purposes.  It  is  used  to  com¬ 
municate  pictures  between  processes,  where  multiple  processes  Eire  being  used  for 
reasons  of  modularity  or  space.  It  is  used  as  the  format  in  which  pictures  resulting 
from  user  programs,  like  sketch  editors  and  animation  systems,  are  stored  on  disk.  It 
is  used  for  programs  that  generate  pictures  but  do  not  know  on  which  device  they  will 
be  output. 

Standard  format  is  a  set  of  instructions  for  a  hypothetical  standard  graphics  device. 
This  device  has  a  screen  of  4096  by  4096  rasters  (infinity  by  infinity  if  the  floating  point 
option  is  used),  intensity  or  colour  levels  between  0  and  255  and  lines  between  0  and  15 
units  thick.  In  addition  to  commands  specifying  the  usual  line-drawing  graphical  primi¬ 
tives,  the  standard  format  has  commands  to  handle  characters  and  character  fonts, 
intensity,  thickness,  colour  control,  and  region  shading.  The  format  used  for  this  infor¬ 
mation  can  be  encoded  or  decoded  very  efficiently.  The  storage  required  by  standard 
format  pictures  is  not  minimal,  but  the  encoding  was  kept  simple  so  that  users  would 
be  more  inclined  to  use  it. 


4.2.2.  GPAC 

GPAC  is  implemented  entirely  in  C.  Its  organization  can  be  divided  into  eight  basic 
modules: 


1.  Segment  Handling  Routines 

2.  Graphical  Primitives 

3.  Transformation  Routines 

4.  Memory  Allocator 

5.  Code  Generator 

6.  Input  Routines 

7.  Film  Routines 

8.  Miscellaneous  Routines 

Figure  4  shows  the  main  module  interrelationships.  Approximately  three  quarters  of 
all  the  GPAC  code  necessary  to  support  one  of  the  graphics  devices  can  also  be  used  to 
support  all  other  devices.  This  three  quarters  of  GPAC  code  is  device-independent.  All 
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device  dependent  routines  are  located  in  the  code  generator  and  input  modules. 

Users  of  GPAC  must  identify  irhen  their  program  is  compiled  what  device  is  to  be  used. 
There  is  one  library  of  device-independent  GPAC  routines  always  linked  with  GPAC  pro¬ 
grams.  Depending  on  the  device  the  user  specifies,  a  device-dependent  GPAC  library  is 
also  linked  in.  Switching  devices  thus  involves  relinking.  A  more  sophisticated  way  to 
implement  device  independence  would  be  to  have  an  execution- time  linkage  loader 
which  could  load  and  link  the  device-dependent  routines  of  a  device  when  the  user  pro¬ 
gram  calls  the  "init”  routine  and  specifies  which  device  he  wants  to  use.  This  has  not 
been  implemented  because  there  was  not  time  to  tackle  this  diffcult  problem.  Another 
solution  would  be  to  load  all  device-dependent  routines  for  all  devices  with  every  GPAC 
program  and  use  a  jump  table  to  call  the  correct  routines  once  the  user  has  specified 
the  device  he  wants,  l^is  solution  would  be  too  costly  because  of  all  of  the  device¬ 
dependent  routines  loaded  but  never  used.  Supporting  five  devices  would  approxi¬ 
mately  double  the  size  of  GPAC  routines  loaded  over  what  is  really  needed. 


4.S.2.I.  Segment  Handling 

The  display  file  is  the  primary  output  data  structure  of  the  output  portion  of  GPAC.  It 
must  be  a  very  dynamic  data  structure  and  one  which  can  be  executed  by  the  refresh 
graphics  devices  that  are  supported.  For  these  reasons  the  display  file  is  organized  as 
a  two  way  linked  circular  list  of  variable-sized  blocks  of  memory.  Each  block  contains 
display  code  instructions. 

The  basic  data  structure  medntained  by  the  segment  handling  routines  is  the  segment 
table  which  identifies  where  the  display  instructions  of  each  segment  stairt  and  end  in 
the  display  file.  The  segment  table  also  contains  a  back  pointer  to  the  previous  block 
in  the  circular  list.  These  values  are  constantly  referenced  and  modified  as  segments 
are  opened,  closed,  appended,  posted,  unposted,  and  deleted.  The  three  pointers  are 
retained  in  the  segment  table  to  provide  maximum  display  file  update  speed.  It  would 
be  possible  to  perform  the  same  function  with  just  the  starting  location,  but  this  would 
require  linear  searches  through  the  display  file. 


4.2.2. 2.  Graphical  Primitives 

The  graphical  primitive  routines  take  the  user  program’s  graphical  information,  pro¬ 
cess  it,  and  then  pass  it  on  to  the  code  generator.  Information  like  intensity,  colour, 
and  line  width  settings  are  passed  directly  to  the  code  generator.  Coordinate  points 
are  first  passed  to  the  transformation  module  where  they  are  translated  by  the  current 
transformation  matrix  and  then  returned.  The  transformed  point  is  clipped  against 
the  window  using  a  clipping  algorithm  presented  in  [Newman  73];  if  a  line  segment  is 
visible  it  is  passed  back  to  the  transformation  module  for  the  window-viewport  transfor¬ 
mation  to  be  applied.  Finally,  the  resulting  line  segment  is  passed  on  to  the  code  gen¬ 
erator.  Clipping  could  be  performed  against  the  viewport  after  the  window- view  port 
transformation  instead  of  against  the  window.  This  is  inefficient,  however,  because 
there  may  be  many  lines  which  could  be  totally  clipped  from  the  picture  by  the  window, 
and  would  then  not  have  to  be  transformed  by  the  window-viewport  transformation. 
For  shaded  areas,  the  "fillbegin”  and  "fillend"  information  is  passed  directly  to  the 
code  generator  and  the  lines  defining  area  boundaries  are  treated  as  normal  lines.  One 
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exception  is  that  when  boundary  lines  lie  outside  the  window,  they  are  not  discarded  as 
are  normal  lines  but  aire  replaced  by  lines  along  the  edges  of  the  window  to  retain  a 
closed  area. 


4. 2.2. 3.  Transformations 

The  transformation  routines  accept  user  requests  for  translation,  seeding,  and  rotation 
and  multiply  the  current  transformation  matrix  by  a  matrix  to  produce  a  new  transfor¬ 
mation.  The  current  transformation  is  a  three  by  three  matrix,  but  only  six  elements 
are  stored,  as  the  third  column  is  constant.  The  transformation  is  applied  by  multiply¬ 
ing  the  matrix  with  the  coordinate  point  vector.  The  transformation  module  maintains 
the  user’s  window  and  viewport  definitions  and  applies  the  window-viewport  transforma¬ 
tion  when  requested.  It  also  maintains  a  dynamically  allocated  stack  on  which  the  user 
can  push  and  pop  the  current  transformation  matrix. 


4. 2. 2. 4.  Memory  Allocator 

The  dynamic  memory  allocator  used  in  GPAC  is  a  modified  version  of  the  boundary  tag 
algorithm  presented  in  [Knuth  68].  When  the  code  generator  requests  a  block  from  the 
allocator,  it  has  no  idea  how  big  a  block  it  will  need.  The  modification  of  the  boundary 
tag  method  is  to  keep  the  available  block  list  sorted  by  size  of  block.  The 
“request-block”  routine  always  returns  the  largest  block  available.  When  a  segment  is 
closed,  the  code  generator  returns  the  unused  portion  of  the  segment's  last  block  to 
the  core  allocator  by  calling  a  “trim-block”  routine.  Entire  blocks  returned  to  the 
core  allocator  by  a  “release— block”  routine  must  first  be  merged  with  neighbouring 
blocks  if  they  are  free.  This  is  determined  by  consulting  their  boundary  tags.  After 
merging  the  resulting  free  block  is  merged  into  the  free  list  by  linear  insertion.  When  a 
segment  is  deleted,  the  blocks  containing  its  display  code  should  be  released  to  the 
core  allocator  immediately  so  that  subsequent  allocations  can  provide  the  largest 
block  available.  Before  releasing  the  blocks,  however,  the  delete  routine  makes  sure 
the  display  is  not  still  executing  display  code  contained  in  them.  If  a  block  was 
released  and  then  reused  by  the  code  generator  while  the  display  was  still  executing  it, 
the  display  file  would  be  overwritten  and  the  display  could  run  wild. 

An  alternative  to  the  boundary  tag  method  is  a  fixed  block  method.  This  has  the  advan¬ 
tages  of  being  easier  to  implement  and  of  producing  no  externed  fragmentation.  Its 
disadvantages  are  that  it  produces  internal  fragmentation,  and  that  control  informa¬ 
tion  needed  to  link  blocks  together  in  the  display  file  uses  valuable  display  file  space. 
Both  methods  experience  the  last  disadvantage  but  the  fixed  block  scheme  usually 
requires  more  blocks  than  the  method  we  have  used. 


4.2.2. 5.  Code  Generator 

The  Graphic  Wonder  is  the  only  device  that  directly  executes  the  display  file  which 
GPAC  generates.  The  Tektronix  is  a  storage  tube  device,  so  that  the  display  file  is  just 
picture  storage  used  to  update  the  screen  whenever  the  user  does  an  update  call.  The 
pictures  are  stored  in  the  display  file  in  standard  format.  Since  the  Null  device’s  pur¬ 
pose  is  to  output  pictures  in  standard  format,  pictures  in  its  display  file  are  also  in 
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standard  format. 


The  Colour  Video  device  has  to  have  a  very  large  display  file  to  cover  the  whole  screen. 
Also,  the  2  1/2  D  scan  conversion  algorithm  is  complicated  and  requires  a  large  pro* 
gram.  Therefore  a  separate  process  is  used  to  do  the  scan  conversion  and  address 
mapping.  The  display  file  in  the  user’s  program  contains  segments  stored  in  standard 
format.  When  the  user  requests  an  update,  GPAC  computes  the  minimum  enclosing 
rectangle  of  the  portions  of  the  display  file  that  have  been  modified  since  the  last 
update.  GPAC  tells  the  scan  converter  process  to  clear  that  portion  of  the  screen  and 
then  transmits  to  it,  in  standard  format,  those  parts  of  the  picture  intersecting  the 
cleared  rectangle.  The  scan  converter  then  only  has  to  rescan  a  portion  of  the  screen. 
An  example  where  this  method  would  be  inefficient  is  where  the  user  makes  small 
modifications  to  the  top  right  and  bottom  left  corners  of  the  screen.  The  minimum 
enclosing  rectangle  will  be  the  whole  screen  which  will  cause  the  entire  picture  to  be 
rescanned.  A  more  efficient  attack  would  be  to  clear  and  rescan  the  two  small  areas 
independently.  As  users  begin  to  use  the  Colour  Video  system,  more  efficient  methods 
will  likely  be  developed. 

Both  the  Graphic  Wonder  and  standard  format  code  generators  use  a  fifo  code  queue  to 
perform  optimizations.  The  graphical  primitive  routines  add  their  transformed  and 
clipped  graphical  information  to  the  end  of  the  queue.  If  there  is  no  room,  the  code 
generator  is  called  to  empty  part  of  the  queue  from  the  front.  Because  the  code  gen¬ 
erator  can  see  what  code  must  be  generated  next  by  looking  down  the  queue,  it  can 
perform  near  optimal  format  changes  and  command  compactions. 


4.2.2. 8.  Input  Routines 

GPAC  currently  supports  graphical  input  routines  for  two  devices,  the  Graphic  Wonder 
and  Tektronix.  Their  respective  input  devices  are  the  digitizing  tablet  and  cross-hairs. 
Input  support  for  the  Colour  Video  and  the  Null  device  is  in  the  planning  stages.  For 
the  Graphic  Wonder,  much  of  the  tablet  support  is  performed  in  system  space  as 
described  earlier.  GPAC  provides  a  friendlier  and  cleaner  user  interface  than  the 
direct  system  calls  needed  to  communicate  with  the  driver.  The  GPAC  “getevent”  rou¬ 
tine  decodes  the  ink  buffer  created  by  the  tablet  during  an  inking  event  into  sets  of 
points  in  screen  coordinates.  Each  set  corresponds  to  one  stroke  drawn  by  the  user. 
These  points  are  stored  in  dynamically  allocated  memory  and  made  available  to  the 
user  when  “getevent”  returns. 

The  Tektronix  cross-hairs  support  is  implemented  entirely  in  user  space.  The  cross 
hairs  are  displayed  by  sending  a  special  sequence  of  characters  to  the  terminal.  By 
reading  characters  from  the  terminal,  the  user’s  interection  can  be  determined  and 
the  user  program  informed.  Because  the  Tektronix  is  a  storage  tube,  not  all  input  func¬ 
tions  are  available;  for  example,  tracking,  equal-time  inking  and  equal-space  inking.  In 
point  mode  inking,  the  rubber  band  effect  can  also  not  be  implemented,  but  the  user, is 
able  to  indicate  point  positions  which  are  joined  by  straight  lines.  The  ink  buffer  is 
returned  to  the  user  in  the  same  way  as  from  the  tablet. 

To  perform  the  “screentouser”  function  which  transforms  screen  coordinates  to  the 
user’s  coordinate  space.  GPAC  finds  the  inverses  of  both  the  window-viewport  transfor¬ 
mation  and  current  matrix  transformation  and  applies  them  to  the  screen  coordinate 
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point. 


4. 2. 2. 7.  Film  Routines 

Film  files  created  by  GPAC’s  film  routines  have  the  following  special  format  designed 
for  maximum  playback  speed.  Each  frame  or  sequence  of  frames  containing  the  same 
image  has  a  header  which  gives  the  following  information: 

1)  —  Frame  number  of  the  first  frame  of  the  sequence 

2)  —  Duration  of  this  sequence  in  frames 

3)  —  Number  of  blocks  in  the  film  file  used  by  the  picture  information  of  this 

sequence  of  frames 

4)  -  Font  used  by  this  sequence  of  frames 

5)  —  Duration  of  the  next  sequence  of  frames  in  the  file 

6)  —  Number  of  blocks  of  the  next  sequence 

7)  —  Font  of  the  next  sequence. 


The  information  oh  the  next  sequence  Is  used  by  the  playback  program  to  read  ahead. 
Following  the  header  is  the  picture  information  of  this  sequence  of  frames.  This  infor¬ 
mation  is  stored  as  a  display  file  which  the  device  can  execute  immediately  without  any 
modifications.  Support  programs  exist  that  translate  film  files  between  the  three  film 
devices;  the  Graphic  Wonder,  the  Colour  Video,  and  the  standard  format  or  null  device. 

The  GPAC  routines  to  create  film  files  are  quite  trivial.  "Beginfilm”  creates  the  file  in 
which  to  store  the  film  and  initializes  the  internal  frame  counter.  The  “frame”  routine 
causes  the  last  frame  to  be  terminated,  the  frame  counter  to  be  updated,  and  a  new 
header  to  be  written.  It  also  goes  back  and  deposits  the  information  of  the  new  frame 
as  the  next  frame  information  in  the  last  header.  The  “include”  routine  consults  the 
segment  table  and  writes  the  portion  of  the  display  file  containing  the  segment  into  the 
film  file.  The  “endfilm”  routine  terminates  the  last  frame  and  closes  the  film  file. 


4.2.2, 8.  Miscellaneous  Routines 

GPAC  is  initialized  by  the  "init”  routine.  Its  duties  are  to  open  the  requested  input  and 
output  devices,  initialize  all  GPAC  internal  variables,  call  the  initialization  routine  of 
each  module,  load  the  font  file  if  the  Graphic  Wonder  is  the  output  device,  and  start  up 
the  scan  converter  process  if  on  the  Colour  Video. 

The  “snap”  routine  is  implemented  by  creating  a  file  and  writing  a  copy  of  the  display 
file  into  it.  Then,  if  the  snap  is  directed  to  a  particular  device,  another  process  is  ini¬ 
tiated  which  reads  in  the  file,  decodes  the  display  file  in  it,  and  displays  the  image  on 
the  requested  device.  A  separate  process  and  intermediate  file  are  used  because  it 
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removes  some  GPAC  code  from  the  user’s  program. 

The  implementation  of  the  remaining  GPAC  functions  should  be  fairly  clear  from  their 
descriptions  presented  in  Chapter  3. 


4.2.3.  Playback 

The  “playback”  program  displays  the  sequence  of  frames  contained  in  a  film  file  on  a 
graphics  device.  To  be  able  to  play  films  in  real  time,  “playback”  uses  the  double 
buffering  technique.  While  it  is  displaying  one  frame  on  the  screen  using  one  half  of  its 
display  file,  it  is  reading  the  next  frame  into  the  other  half.  The  information  in  frame 
headers  makes  reading  frames  efficient  because  the  header  of  the  next  frame  does  not 
have  to  be  read  to  find  its  size.  It  is  already  in  the  header  of  the  current  frame.  There¬ 
fore  a  frame  caji  be  read  with  one  read  operation  instead  of  two. 

Minor  modifications  to  UNIX's  “time  of  day”  routines  have  allowed  user  programs  to 
determine  the  time  of  day  and  delay  their  execution  (i.e.,  put  their  process  to  sleep  for 
a  specified  time)  by  some  multiple  of  a  sixtieth  of  a  second.  Playback  uses  these  rou¬ 
tines,  and  the  input  parameters  of  frames  per  second,  starting  frame,  and  frame  incre¬ 
ment,  to  determine  what  frame  should  currently  be  displaying  on  the  screen.  When  it 
has  read  the  next  frame  into  the  double  buffer,  playback  will  delay  itself  if  the  current 
frame  being  displayed  is  the  same  as  the  one  it  should  be  showing.  If  it  has  fallen 
behind,  it  immediately  displays  the  new  frame  and  starts  the  read  of  the  next  in  an 
attempt  to  catch  up. 

To  enable  “playback”  to  catch  up  more  efficiently  when  it  has  fallen  behind,  an  agenda 
of  the  film  could  be  created  in  the  film  file  or  in  a  separate  file.  “Playback”  could 
immediately  skip  all  frames  needed  to  catch  up  with  one  disk  seek,  as  opposed  to  mul¬ 
tiple  seeks  and  reads  needed  in  the  method  described  above.  The  disadvantage  of  stor¬ 
ing  films  in  this  format  is  that  frames  do  not  stand  alone  but  are  bound  together  by  the 
agenda.  Thus  it  is  not  as  easy  to  “cut  and  paste”  films  together  from  multiple  film 
files.  With  this  structure  it  is  also  not  possible  to  play  a  film  back  from  magnetic  tape. 

By  storing  the  film  file  in  a  special  raw  disk  file  available  to  all  users,  “playback”  is  able 
to  show  films  at  higher  speeds.  This  is  because  data  read  from  raw  files  is  transferred 
directly  to  playback’s  display  file  rather  than  passing  through  internal  operating  sys¬ 
tem  buffers  on  the  way. 

“Playback”  is  able  to  show  films  and  watch  for  user  commands  at  the  same  time 
because  it  is  actually  two  processes  executing.  Normally  the  command  monitor  pro¬ 
cess  is  watching  the  input  for  valid  commands  while  the  other  process  is  playing  back 
the  film  or  waiting  to  be  started  or  continued.  When  the  command  monitor  recognizes 
a  valid  command,  it  signals  the  other  process,  which  causes  it  to  read  the  command 
and  act  upon  it. 
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4.2.4.  Scroller 


The  Graphic  Wonder  scroller  treats  its  display  file  as  a  leirge  circular  buffer  of  charac¬ 
ters.  For  each  line  of  characters  displayed  on  the  screen,  there  is  a  pointer  into  the 
buffer  to  where  the  line  stairts  and  a  count  of  the  number  of  characters  in  the  line. 
There  is  also  a  pointer  and  count  for  the  positions  in  the  buffer  not  currently  contain¬ 
ing  characters.  When  the  scroller  reads  characters  from  the  special  pseudo  device  set 
up  by  the  Graphic  Wonder  keyboard  driver,  they  are  placed  in  the  next  free  position  in 
the  free  area.  The  pointers  and  counts  of  the  current  line  and  the  free  area  are 
updated  accordingly.  When  the  scroller  starts  a  new  line,  it  deletes  the  top  line  it  was 
displaying  and  returns  its  storage  to  the  free  area.  By  remembering  the  number  of 
characters  in  the  current  line,  it  can  wrap  and  indent  a  line  which  is  too  long  onto  the 
next  line  and  handle  tab  and  backspace  characters  correctly.  The  scroller  remembers 
the  number  of  lines  currently  on  the  screen  and  does  not  delete  the  top  line  if  more 
lines  can  still  be  displayed.  By  controlling  the  screen  position  of  the  first  character  in 
the  first  line  and  altering  the  newline  character  in  the  character  font,  lines  are  aligned 
at  the  left  edge  of  the  user  defined  viewport. 

The  scroller's  special  commands  are  encoded  as  escaped  character  sequences  that  are 
not  expected  in  normal  text.  The  clear  command  is  just  an  initiedization  of  the  charac¬ 
ter  buffer  and  the  scale  command  is  achieved  with  a  hardware  scale  command  in  the 
display  file. 


4.2.5.  Scan  Converters 

Two  scan  converters  are  being  used  in  the  graphics  system.  One  uses  the  file  system  to 
implement  a  virtual  buffer  in  which  to  scan  convert  pictures.  This  algorithm  is  used  for 
complicated  pictures  and  is  not  very  fast.  The  second  algorithm,  using  the  algorithm 
presented  in  [Jordan  73],  is  more  efl^cient. 


5.  Conclusions 

This  chapter  describes  developments  in  the  graphics  system  more  recent  than  January 
of  1976.  It  discusses  how  well  the  goals  of  the  system  have  been  achieved.  Areas  of 
future  research  and  development  are  examined.  Finally,  a  presentation  of  some  of  the 
past  and  current  applications  of  the  system  are  given. 


5.1.  More  Recent  Developments 

Since  January  1976  when  the  work  described  in  the  preceding  chapters  was  completed, 
our  graphics  system  has  evolved  in  many  directions.  Due  to  space  limitations  exact 
details  and  implementation  considerations  cannot  be  given  here.  Instead,  only  the 
major  areas  of  development  are  outlined  below. 

•  A  generalized  three-dimensional  line  drawing  package  was  built  upon  GPAC. 

•  A  GPAC  routine  allowing  character  strings  to  be  scaled,  rotated,  and 

translated  by  the  user-specified  transformation  parameters  was 
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implementecL 

•  A  series  of  GPAC  routines  to  input  pictures  in  standard  format  was  imple¬ 

mented. 

•  Various  GPAC  routines  for  segment  handling  were  written  (e.g.,  postedseg, 

definedseg,  nextavailseg  —  see  Appendix  A  for  a  complete  list). 

•  Various  special  secret  routines  were  written  to  utilize  special  hardware 

features  of  some  devices.  This  is  contrary  to  device-independence  but 
they  were  easy  to  implement  and  yeilded  great  efficiencies  in  some 
applications  (see  Appendix  A  for  details). 

•  Inking  was  made  more  flexible.  Start  conditions  are  now  user  settable  and 

button  release  conditions  were  added  to  the  possible  termination  con¬ 
ditions.  It  is  also  now  possible  to  ink  without  leaving  an  ink  trail. 

•  GPAC  has  been  interfaced  to  two  new  devices:  the  DEC  VT52  and  the  ARDS 

lOOB 

•  Operating  system  interfaces  have  been  implemented  for  the  slider  box  which 

is  a  new  input  device  having  two  infinite  sliders  and  four  toggle 
switches.  User  interactions  with  the  device  are  now  handled  by  the 
GPAC  getevent  routine. 

•  An  entire  package  of  routines  was  written  to  handle  the  colour  video  device  as 

a  frame  buffer. 

•  The  tablet  driver  now  implements  tracking  and  inking  on  the  colour  video. 

•  A  redesign  of  the  standard  graphics  format  has  just  occurred.  Transforma¬ 

tion  of  existing  software  is  now  under  way. 

•  A  UNIX  batch  version  of  GPAC  has  been  implemented.  Its  output  devices 

include  a  line  printer  and  a  Zeta  pen  plotter. 

•  A  version  of  the  operating  system  modifications  to  UNIX  described  in  the 

preceding  chapters  has  been  written  for  and  tested  on  a  PDP-11/40 
which  does  not  have  separate  instruction  and  data  space. 

•  Software-defined  character  fonts  have  been  designed  and  programs  written  to 

display  them  on  the  Versatec  printer/plotter.  These  were  then  inter¬ 
faced  to  the  UNIX  typesetting  system  "troff”  to  form  a  general  purpose 
document  formatting  and  typesetting  facility. 
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5.2.  Review  of  Goals 

By  embedding  GPAC  in  C,  the  graphics  system  is  accessible  through  a  high-level 
language.  The  system  was  then  easily  transferred  to  the  language  SLOGO  [Duff  76]  as  it 
was  based  on  C.  Because  of  separate  compilation  of  C  subroutines,  it  would  be  possible 
to  easily  interface  other  languages,  but  we  have  not  had  the  demand  for  this  yet. 

The  use  of  segments  in  GPAC’s  output  section  adds  structure  to  pictures.  In  an  interac¬ 
tive  environment  where  partial  updating  of  the  screen  is  very  common,  this  structure 
is  invaluable.  For  graphical  input,  the  event  concept  allows  the  high-level  treatment  of 
user  interactions.  It  avoids  the  device  polling  mechanisms  found  in  some  graphics  sys¬ 
tems.  We  have  found  the  number  of  events  desired  by  the  user  community  always 
exceeds  the  number  implemented.  In  general,  GPAC  is  a  simple  yet  powerful  user 
interface  which  succeeds  very  well  in  hiding  most  of  the  device-dependent  features  of 
graphics  devices. 

The  graphics  system  is  general-purpose.  The  user  interface  was  kept  simple  so  that 
various  applications  could  build  upon  it  without  unnecessary  overhead.  Because  GPAC 
was  embedded  in  C,  any  C  program  can  display  graphics.  The  system  has  been  used  by 
approximatly  15  graduate  students  in  their  thesis  research.  It  is  currently  being 
heavily  used  by  a  major  project  studying  human-machine  interfaces  in  computer 
music.  The. system  has  been  used  for  3  years  in  a  graduate  level  computer  graphics 
course  (15  students  each  year)  and  for  2  years  in  an  undergraduate  level  graphics 
course  (50  students  each  year).  It  has  been  used  for  countless  hours  by  hordes  of  mid¬ 
night  hackers  ^  It  has  been  distributed  to  over  20  other  educational  UNIX  installa¬ 
tions. 

Device-independence  has  been  achieved.  The  user-interfaces  of  GPAC  for  each  device 
are  identical,  as  is  three  quarters  of  the  actual  code  -  only  one  quarter  is  device- 
dependent.  Devices  which  cannot  perform  some  user  request,  because  of  some 
hardware  limitation,  ignore  it  if  totally  unreasonable  or  attempt  through  some  other 
means  to  achieve  a  similar  result.  The  use  of  standard  format  as  a  representation  of 
graphic  images  is  an  attempt  to  attain  device-independence  among  programs  generat¬ 
ing  pictures  to  be  used  by  other  programs  or  to  be  sent  to  an  unknown  device.  It  has 
been  very  successful  especially  in  the  sharing  of  picture  data.  The  design  decision  to 
maintain  a  simple  format  has  been  highly  rewarding. 

Of  all  the  goals,  real-time  response  has  been  the  most  difficult  to  achieve.  The  tablet 
driver  has  achieved  good  response  for  user  interactions,  especially  for  inking,  but  at 
the  expense  of  putting  the  code  into  the  operating  system.  Even  if  the  user  interaction 
is  recognized  in  real  time,  the  user  space  program  waiting  for  the  event  must  wait  until 
the  UNIX  scheduler  gives  it  a  time-slice  in  which  to  execute.  This  is  where  the 
automatic  cursor  mechanisms  are  important.  User  programs  attempting  to  poll  the 
tablet  encounter  problems  because  they  are  being  time-shared  with  other  processes. 
We  have  not  implemented  any  of  the  mechanisms  for  enabling  a  process  to  attain  a 
real-time  status  due  to  a  lack  of  manpower  and  the  desire  for  portability  reasons  to 
avoid  too  many  modifications  to  UNIX. 


*  Usually  graduate  students  in  disguise. 


-  38  - 


The  other  goals  of  creating  a  device-independent  and  general-purpose  system  have  hin¬ 
dered  the  achievement  of  real-time  response.  In  a  device-independent  system,  special 
hardware  features,  available  on  only  some  of  the  devices,  are  often  not  used  to  help 
response  because  that  would  be  device-dependent.  Similarly,  standard  format,  which 
was  developed  to  obtain  device-independence,  is  a  bit  inefficient  for  real-time  response 
because  an  intermediate  representation  of  pictures  must  be  translated  to  the  device's 
format  to  be  displayed.  An  application  could  attain  better  real-time  response  in  a 
graphics  system  designed  directly  for  itself  than  in  a  general-purpose  system.  For 
example,  an  application  may  be  able  to  do  without  the  transformations,  clipping,  win¬ 
dowing,  and  segmentation  provided  by  GPAC.  We  have  decided  that  the  device¬ 
independent  and  general-purpose  goals  are  more  important  than  real-time  response 
goal.  We  base  this  tradeoff  decision  on  the  fact  the  system  will  mainly  be  used  for  pro¬ 
gram  development  as  opposed  to  real-time  production  When  it  is  necessary  to  attain 
real-time  response  to  test  a  program,  the  user  generally  asks  others  to  be  as  quiet  as 
possible  for  the  next  short  while  This  effectively  gives  the  user  access  to  all  the 
resources  available  on  the  machine. 

The  graphics  system  has  been  able  to  preserve  time-sharing  quite  well.  When  the 
tablet  is  used  for  inking,  it  is  hardly  noticeable  to  other  users.  When  large  graphics 
programs  run,  the  overall  system  performance  does  degrade  —  but  this  can  be 
expected  for  any  large  program.  No  other  parts  of  the  system  are  able  to  effect  time¬ 
sharing  because  real-time  status  has  not  been  implemented  for  them.  A  new  version  of 
playback  has  been  implemented  which  detects  when  it  has  fallen  behind  and  seeks  for¬ 
ward  in  the  display  file  to  display  the  correct  frame. 

Following  the  philosophy  of  UNIX  has  been  a  useful  goal.  Only  a  few  fundamental 
changes  have  been  made  to  the  operating  system.  Most  of  the  new  additions  have  been 
device  drivers  which  any  installation  is  expected  to  add.  The  graphics  system  has 
already  been  transferred  from  Version  5  to  Version  6  of  UNIX  with  relatively  little 
difficulty.  In  user  space  many  graphic  commands  have  been  created,  especially  ones 
dealing  with  standard  format.  The  ideas  of  sources,  sinks,  and  filters  are  often  used  in 
reguleir  UNIX  commands.  The  use  of  multiple  processes  to  work  together  towards  a 
common  goal  is  also  often  used  in  UNIX.  We  believe  that  the  set  of  graphics  tools  pro¬ 
vided  by  this  system  for  writing  graphics  programs  are  nearly  as  powerful  as  those  pro¬ 
vided  by  UNIX  to  write  programs  in  general. 

The  implementation  is  fairly  efficient.  During  its  development  inefficient  sections  were 
removed  or  redesigned.  Approximately  3.5K  words  of  system  space  has  been  used  to 
implement  graphics  drivers.  GPAC  normally  occupies  5K  words  of  a  user  program’s 
address  space.  The  entire  system,  except  for  20  lines  of  assembler  code  in  the  operat¬ 
ing  system,  is  implemented  in  C.  The  C  compiler  produces  extremely  well  optimized 
code.  Apart  from  its  lack  of  strong  type  checking,  C  is  a  very  powerful  language. 


^  There  have  been  times  when  we  have  wanted  to  do  production  work  and 
have  been  frustrated  -  but  tradeoffs  have  to  be  made.  Thankfully  most 
of  our  work  is  development. 

^  Our  lab  and  users  are  usually  quite  friendly  in  this  regard. 
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The  mapping  of  the  display  file  into  user  address  space  has  greatly  increased  the 
efficiency  of  display  file  management.  Most  of  the  time  spent  in  the  output  portion  of 
GPAC  is  in  the  transformation,  clipping,  windowing,  and  code  generator  routines.  The 
interrupt  routine  of  the  tablet  is  another  critical  area  because  it  handles  so  much  data. 
Attempts  have  been  made  to  optimize  these  areas.  The  effects  of  implementing  this 
system  on  a  minicomputer  were  felt  in  many  design  decisions.  Limited  total  memory 
size  and  program  addressability  have  had  a  particularly  leirge  influence. 


5,3.  Future  Development 

This  graphics  system  has  evolved  a  long  way  since  its  beginnings  three  and  a  half  years 
ago.  During  that  time  some  design  and  implementation  mistakes  were  made,  but  time 
has  been  available  to  experiment  with  different  approaches  until  a  good  solution  was 
found.  At  the  time  of  this  writing  the  system  is  fairly  stable  --  it  is  being  heavily  used 
for  applications.  Nevertheless,  there  are  some  improvements  and  additions  planned 
for  the  future. 

A  new  set  of  device-dependent  GPAC  routines  will  have  to  be  written  for  a  new  seg¬ 
mented  colour  video  graphics  device  being  built  by  David  Miller  of  our  group  [Miller  78]. 
Its  instruction  format  will  resemble  that  of  the  Graphic  Wonder  and  so  should  be  easy 
to  interface.  Its  added  features  include  dynamic  filled  regions  of  colour  at  variable 
depths.  Plans  are  also  underway  to  implement  GPAC  for  the  DEC-GT41  display  as  well 
as  the  Varian  printer/plotter. 

Mark  Green  of  our  group  is  currently  investigating  graphics  input  for  his  Master’s 
thesis.  Some  of  his  ideas  on  events,  polling,  input  device  independence,  and  user  feed¬ 
back  mechanisms  will  probably  find  their  way  into  the  system.  Concurrently,  the  slider 
box  interface  is  being  redesigned.  This  will  require  minor  operating  system 
modifications  but  no  user  incompatibilities. 

More  work  needs  to  be  done  in  the  area  of  raster  scan  devices.  New  represenations  of 
area  shaded  pictures  as  well  as  algorithms  for  fast  scan  conversion,  texturing,  and 
jagged  edge  removal  are  needed. 

Another  area  to  be  looked  at  is  structured  playback  files.  Instead  of  saving  films  as  a 
sequence  of  frames,  they  would  be  stored  as  a  set  of  picture  segments  and  an  agenda. 
The  agenda  would  specify  what  segments  are  visible  during  each  frame. 

GPAC  may  be  extended  to  allow  two  processes  to  share  the  same  display  file.  This 
would  involve  sharing  the  same  memory  allocation  data  and  implementing  some  syn¬ 
chronization  eind  mutual-exclusion  primitives.  Another  extention  allowing  access  to 
multiple  output  devices  at  once  may  also  be  implemented. 

The  proposed  general  reed-time  mechanism  suggested  in  the  preceding  chapters 
currently  has  low  priority.  It  would  involve  changes  to  UNIX’s  swapping  and  scheduling 
strategies.  First  of  all,  a  real-time  process  would  have  to  be  locked  into  core  and  not 
be  allowed  to  swap  out.  Problems  involved  in  this  include  positioning  the  process  in 
core  so  that  it  would  leave  remaining  memory  as  contiguous  as  possible,  and  watching 
for  deadlock  situations  involved  in  tying  down  core  for  an  unknown  period  of  time. 
Another  problem  to  solve  is  how  to  allow  real-time  processes  to  allocate  core 
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dynamLcally.  The  current  UNIX  solution  is  to  swap  processes  out  and  swap  them  in  at  a 
larger  size.  Secondly,  a  modification  to  the  scheduler  may  be  necessary  to  give  a  real¬ 
time  process  a  more  favourable  time-slice.  This  could  be  achieved  by  giving  the  pro¬ 
cess  a  high  priority  and  not  letting  the  scheduler  decrease  it  as  the  process  uses  up 
resources.  Only  privileged  processes  would  be  allowed  to  gain  real-time  status. 

At  some  time  the  whole  view  of  this  graphics  system  euid  the  way  it  has  been  interfaced 
with  UNIX  should  be  reexamined  to  identify  the  features  needed  in  an  operating  system 
to  support  real-time  computer  graphics.  Another  area  yet  to  be  investigated  at  the 
University  of  Toronto  is  the  use  of  microcomputers  to  run  interactive  graphics  stations 
and  a  high-speed  line  to  communicate  with  the  main  time-sharing  system. 


5.4.  Current  Applications 

This  section  contains  sample  output  from  various  application  programs  developed  by 
members  of  the  Dynamic  Graphics  Project  at  the  University  of  Toronto. 

Figure  5  is  a  sample  frame  from  a  bus  simulation  movie  created  by  Tom  Duff’s  simula¬ 
tion  system,  SLOGO  [Duff  76].  Figure  8  shows  the  screen  layout  of  the  HAFWIT  sketch¬ 
ing  package  written  by  Greg  Hill.  A  sample  page  from  David  Tilbrook’s  newspaper  page 
layout  system,  Newswhole  [Tilbrook  77],  is  shown  in  Figure  7.  A  sample  "worm”  gen¬ 
erated  by  Mike  Tilson’s  Paterson’s  Worm  program  is  shown  in  Figure  8.  Figure  9  is  a 
freune  from  a  movie  being  made  by  Martin  Tuori  with  his  animation  system  [Tuori  77]. 
Figure  10  is  a  frame  from  the  Kepler  system  of  Robert  Pike  for  meiking  movies  of  plane¬ 
tary  motion  [Pike  77].  Figures  11  and  12  are  snapshots  of  two  interactive  music  score 
editors  being  designed  for  the  Structured  Sound  Synthesis  Project  [Buxton  78].  Figure 
11,  using  common  music  notation,  is  the  program  “ludwig"  by  the  author  and  Robert 
Pike.  Figure  12,  using  "piano-roU”  notation,  is  the  program  "scored"  by  Steve  Hume, 
The  same  score  is  being  displayed  in  both  figures.  Figures  13  and  14,  also  from  the 
SSSP,  are  two  examples  of  object  or  timbre  definition.  Figure  13  is  from  the  program 
"objed”  by  Bill  Buxton.  Figure  14  was  taken  from  "voice",  a  program  by  Paul  Chow  and 
Dave  Galloway.  Figure  15  is  a  frame  from  a  movie  being  made  by  Ron  Baecker  and  Dave 
Sherman  on  sorting  techniques.  Finally,  this  document  and  the  accompanying  GPAC 
manual  are  good  examples  of  the  typesetting  system. 


5.5.  Summary 

The  graphics  system  presented  in  this  report  has  been  quite  successful  in  meeting  its 
goals.  It  has  involved  a  very  large  amount  of  work  in  modifying  an  operating  system  to 
accommodate  interactive  graphics  and  then  creating  a  high-level,  general-purpose,  and 
device-independent  user  interface.  The  system  has  allowed  the  creation  of  many 
graphics  application  programs  in  relatively  short  periods  of  time.  It  is  currently  being 
run  as  a  production  system  for  a  user  community  of  approximately  thirty-five  students  - 
performing  research  or  enrolled  in  a  graduate  level  computer  graphics  course.  The 
success  of  the  system  is  best  exemplified  by  the  intense  activity  in  interactive  com¬ 
puter  graphics  at  the  University  of  Toronto. 
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2.  APPENDIX  A:  The  GPAC  Users'  Manual 
This  Appendix  presents  the  current  version  of  the  GPAC  Users’  Manued. 
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A  bstract 


GPAC  is  a  set  of  device-independent,  interactive  graphics  routines  avail¬ 
able  in  the  C  language  under  the  UNIX  Time-Sharing  system  at  the  Univer¬ 
sity  of  Toronto.  Facilities  are  provided  for  generating  both  line  drawing 
and  area  shaded  pictures  on  a  variety  of  storage,  raster  scan  and  refresh 
graphics  terminals.  An  event-driven  input  mechanism  allows  interactive 
programming  of  stylus  tracking  and  inking,  light  button  interactions,  and 
device  polling. 
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Section  I  -  Introduction 


GPAC,  which  stands  for  Graphics  PACkage,  is  the  major  user  interface  to  the  graphics 
system  developed  on  UNIX  at  the  University  of  Toronto.  With  it,  programs  written  in 
the  high-level  language  C  can  produce  graphical  output  on  a  wide  variety  of  graphics 
devices  and  receive  graphical  input  from  several  input  devices. 

This  manual  presents  GPAC  in  six  sections  entitled:  Graphical  Output,  Graphical  Input, 
Film  Routines,  Standard  Format,  Initialization  and  Termination,  and  Auxiliary  routines. 
Each  section  describes  a  series  of  GPAC  routines  that  the  user  may  cadi.  The  routines 
used  by  a  user  are  automatically  loaded  from  a  series  of  GPAC  Libraries.  The  types  of 
the  arguments  and  any  values  returned  by  the  routine  are  described.  A  series  of 
appendices  supply  information  on  access  to  GPAC,  support  programs,  a  GPAC  Tutorial 
Guide,  error  messages  and  device  dependencies. 


-1- 


GPAC  Users*  Manual 


Graphical  Output 


Section  II  -  Graphical  Output 


Graphical  output  in  GPAC  can  be  further  subdivided  into  three  parts:  Segment  handling 
routines,  Graphical  primitives  auid  Transformation  routines. 

Some  of  GPAC*a  procedures  deal  with  “segments”.  A  segment  is  a  collection  of  lines, 
filled  regions  and  characters  which  are  generated  by  other  procedures  called  graphical 
primitives.  The  lines  in  a  segment  are  not  visible  on  the  screen  until  GPAC  is  signalled 
to  display  them;  this  process  is  called  “posting”  a  segment.  A  segment  is  removed 
from  the  screen  by  “unposting”  it. 

For  some  devices  GPAC  implements  a  “virtual”  screen;  that  is,  the  screen  is  a  concept, 
it  does  not  actually  exist.  When  an  image  becomes  "visible”  on  this  virtual  screen,  it 
can  not  be  seen  by  the  prograimmer  except  in  his  mind's  eye.  In  order  to  really  see  the 
image,  GPAC  must  be  signalled  to  copy  the  virtual  screen  image  onto  the  output 
medium.  Thus,  any  line  of  a  segment  must  pass  through  three  stages  before  it 
becomes  visible:  first,  not  visible  at  all;  second,  visible  only  on  the  virtual  screen;  and 
third,  on  the  virtual  screen  and  drawn  on  the  output  medium.  On  other  devices  the  vir¬ 
tual  screen  is  the  real  screen.  In  these  cases  lines  only  pass  through  two  stages. 


Segment  Handling 


The  display  screen  in  GPAC  is  represented  as  more  than  just  a  linear  list  of  graphics 
primitives  such  as  line  or  move;  it  can  be  divided  into  segments.  Segments  allow  the 
independent  manipulation  of  logical  portions  of  the  picture  and  also  the  overlaying  of 
entities  in  the  picture  regardless  of  their  creation  sequence.  The  user  program 
creates  a  segment  by  opening  it,  specifying  graphical  primitives  to  be  included  in  it, 
and  then  closing  it.  To  enable  later  reference  and  manipulation  a  segment  number  is 
assigned  to  each  segment  by  the  user. 

gopBnfsegment^number)  ~  A  new  segment  is  opened  to  receive  graphical  primi¬ 
tives.  It  is  assigned  the  specified  number  which  must  be  an  integer  in  the 
range  1  to  num_segs,  where  num^segs  is  specified  in  the  init  call  (Sec¬ 
tion  VI).  If  a  segment  previously  had  been  created  with  the  same  segment 
number,  it  will  be  replaced  by  the  new  segment  as  soon  as  it  is  closed. 
Only  one  segment  may  be  open  at  any  one  time.  All  subsequent  graphical 
primitives  will  be  added  to  this  currently  open  segment. 

gclosefj  “  This  routine  closes  the  currently  open  segment,  indicating  all  graph¬ 
ics  primitives  have  been  added.  Any  existing  segment  with  the  same  seg¬ 
ment  number  as  the  currently  open  segment  is  deleted.  The  segment 
does  not  automatically  become  visible  on  the  screen-it  still  has  to  be 
posted. 
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append('se5rmeni_n7xm6€rj  —  This  routine  allows  the  indicated  segment  to  be 
reopened,  becoming  the  currently  open  segment.  All  subsequent  graph¬ 
ics  primitives  are  added  to  it  until  it  is  closed  again.  The  primitives  are 
added  at  the  segment’s  end.  No  positional,  intensity,  transformation,  or 
other  information  is  retained  since  the  last  time  the  segment  was  open. 
The  user  is  cautioned  that  these  values  are  not  automatically  restored. 
Appending  to  a  nonexistent  segment  is  an  error.  Appending  to  a  posted 
segment  causes  the  newly  added  portions  to  become  visible  when  it  is 
closed  again.  The  already  existing  portions  remain  visible  throughout. 
New  primitives  appended  to  an  unposted  segment  also  remain  unposted. 

delete fsesrme7if_ni£m6erj  --  The  segment  with  the  specified  segment  number  is 
deleted.  The  only  means  of  regaining  it  is  through  the  gopea..,gcIose 
sequence.  Deleting  a  nonexistent  segment  is  an  error. 

postfsegfmenf_num6erJ  —  When  a  segment  is  posted  it  becomes  visible  on  the 
virtual  screen.  When  a  new  segment  is  closed  it  is  left  unposted  and  a  call 
to  post  is  required  to  make  it  visible.  A  call  to  post,  when  there  is  a 
currently  open  segment  with  the  same  segment  number  as  the  argument 
to  post,  will  close  that  segment  and  then  post  it.  Thus  the  sequence, 
gopea(n)...post(D),  will  create  segment  n  and  display  it  immediately. 
Posting  a  nonexistent  segment  is  an  error. 

unpostfse5rmenf_nu7n6erj  —  Unpost  is  the  inverse  of  post.  It  causes  the  seg¬ 
ment  indicated  to  be  removed  from  the  screen,  but  does  not  delete  its 
information.  At  a  later  time  the  segment  can  be  posted  again  by  using 

post. 

depthf^segrTTienf^niimber,  depth_factoT)  —  GPAC  has  facilities  for  performing  2- 
1/2-D  hidden  surface  elimination  of  areas  defined  by  the  graphics  primi¬ 
tives,  fillbegin  and  fillend  (see  below).  It  is  necessary  to  assign  a  depth  or 
priority  to  each  segment  so  that  area  overlap  computations  can  be  made. 
The  routine  depth  assigns  a  depth  factor  to  the  indicated  segment.  Depth 
factors  must  be  positive  integers,  with  higher  values  indicating  further 
distances  from  the  screen  into  the  distance  (i.e.,  less  priority  and  more 
likely  to  be  overlapped).  Within  a  segment,  there  may  be  more  than  one 
filled-in  area  so  the  order  of  creation  within  the  segment  is  used  as  the 
inverse  of  the  depth  factor.  That  means  the  earliest  areas  are  overlapped 
by  the  following  areas.  Another  way  of  putting  it  is  to  say  that  depth  fac¬ 
tor  decreases  within  a  segment. 

updatefj  -  The  speed  at  which  the  picture  can  be  changed  on  the  screen  is  dev¬ 
ice  dependent.  On  raster  scan  devices  a  scan  conversion  must  be  done  on 
the  affected  part  of  the  screen.  On  storage  tubes  it  is  necessary,  if 'a 
deletion  or  unposting  occurs,  to  clear  the  whole  screen  and  redraw  all  the 
remaining  visible  segments.  To  minimize  scan  conversion  or  screen 
clearings,  the  routine  update  is  provided  for  these  types  of  devices  to  sig¬ 
nal  when  to  transfer  the  picture  on  the  virtual  screen  onto  the  output 
device.  Between  calls  to  update  the  normal  picture  modifying  routines 
(e.g.,  post,  unpost,  delete,  append,  clear,  result  in  changes  to  the  display 
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file  (  GPAC*s  internal  storage  area)  but  not  to  the  picture  on  the  screen. 
When  update  is  next  called,  the  picture  on  the  screen  is  updated  to 
correspond  exactly  to  that  currently  in  the  display  file.  On  refresh 
screens  (i.e.,  screens  where  the  virtual  screen  is  the  real  screen),  picture 
modifying  routines  are  performed  immediately  and  update  is  treated  as  a 
nop.  In  the  case  of  the  null  device,  an  update  is  the  signal  to  write  out 
the  standard  format  representation  of  the  picture  (See  Appendices  I  and 
II). 


Graphical  Primitives 


Graphical  primitives  are  used  to  specify  the  basic  picture  elements  of  GPAC:  straight 
lines,  bleink  lines,  filled  curves  and  characters.  Positioning  of  these  primitives  is  done 
anywhere  in  the  real  cartesian  coordinate  system  (up  to  machine  precision),  with  x  in 
the  horizontal  direction  and  y  in  the  vertical.  The  last  x-y  position  referenced  by  the 
user  is  maintained  by  GPAC  as  the  current  position. 

movetofr,  y)  ~  This  function  sets  the  current  position  to  (x,  y).  In  eff'ect  ein 
invisible  line  is  drawn  from  the  current  position  to  the  point  ( x,  y). 

movefdr,  dy)  —  The  current  position  is  moved  by  dx  in  the  x  direction  and  dy  in 
the  y.  An  invisible  line  of  these  dimensions  is  thus  drawn. 

linetofx,  y)  —  k  visible  line  is  drawn  from  the  current  position  to  the  point  (x,  y). 
The  current  position  becomes  (x,  y). 

linef dx,  dy)  —  A  line  is  drawn  from  the  current  position  to  a  point  offset  by  dx  in 
the  X  and  dy  in  the  y  directions.  The  current  position  is  set  to  this  point. 

intensfintn)  —  This  routine  causes  all  subsequent  lines  and  filling  to  be  drawn  at 
the  indicated  intensity.  Intensity  values  valid  for  this  routine  are  0-15, 
independent  of  device.  The  default  intensity  is  15.  GPAC  may  do  remap¬ 
ping  of  these  values  to  transform  them  to  specific  hardware  intensities  or 
to  colours  (See  Appendix  V). 

colourfcoirj  ~  Colour  causes  all  subsequent  lines  and  filling  to  be  done  with  the 
indicated  colour.  A  colour  is  an  integer  in  the  range  1-255.  Once  again 
GPAC  may  do  a  remapping  of  this  standard  range,  to  arrive  at  values 
matching  a  particular  device's  intensity  levels.  On  non-colour  devices, 
the  colour  is  mapped  into  intensity  levels.  The  default  colour  is  255. 

fillbeginfj  —  The  beginning  of  the  definition  of  a  filled  area  or  polygon  is  signaled 
by  this  routine.  An  area's  boundaries  are  defined  by  means  of  a  moveto 
or  move  followed  by  Lineto*s  or  line’s.  If  the  coordinates  of  the  endpoint 
of  the  last  lioeto  do  not  coincide  with  those  of  the  initial  moveto.  GPAC 
inserts  a  lineto  to  join  up  the  points,  thus  closing  the  area.  The  area  is 
filled  with  the  current  colour  or  intensity.  Holes  may  be  added  to  an  area 
by  using  several  moveto-lineto-lineto-...  sequences  within  a 
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fillbejg^...fillend  pair.  The  closed  curves  may  cross,  but  this  may  pro¬ 
duce  unexpected  results  at  times. 

fillendfj  —  This  routine  indicates  the  end  of  an  area  definition.  Fillbegin  and 
fillend  must  be  used  in  matching  pairs  which  cannot  be  nested.  They 
must  also  be  used  only  when  a  segment  is  open.  There  can  be  many  areas 
defined  by  their  own  fillbegin-fillend  pairs  within  a  segment.  Within  a  seg¬ 
ment,  areas  defined  last  will  overlay  those  created  earlier. 

rgb(coLour_nu7nber.  red,  green,  blue)  —  As  indicated  in  the  colour  routine,  the 
user  can  select  a  colour  from  among  255  different  ones  at  any  given  time. 
But  he  can  set  each  one  of  these  to  one  of  more  than  one  billion  colours 
by  calling  the  routine  rgb.  The  indicated  colour_number  (an  integer 
between  1-255)  is  set  to  a  colour  having  the  indicated  red,  green  and  blue 
components.  Each  component  is  represented  as  a  double  floating  point 
value  in  the  range  0.0  to  1.0  with  0.0  specifying  the  minimum  and  1.0  the 
maximum  intensity  for  that  component  in  the  overall  colour.  Currently 
the  hardware  does  not  support  rgb. 

background^ coir)  --  The  background  colour  is  set  to  the  indicated  user  colour. 
Thus  coir  must  be  in  the  range  1-255.  Currently  the  hardware  does  not 
support  background. 

width)  —  On  a  raster  scan  device,  it  is  important  to  be  able  to  specify  the 
width  in  rasters  of  lines  drawn.  All  lines  drawn  after  a  call  to  Iwidth,  will 
be  drawn  width  rasters  wide.  The  default  line  width  is  1. 

charsf string)  —  The  specified  string  is  drawn  with  the  current  position  being  the 
lower  left  corner  of  the  first  character.  The  current  position  is  not 
changed.  The  characters  are  drawn  parallel  to  the  x  axis.  For  the  device 
dependent  character  sizes  and  spacings,  see  Appendix  V. 

All  graphical  primitives  with  the  exceptions  of  intens,  colour,  rgb,  background,  and 
Iwidth.  must  be  used  within  a  gopen...gclose  or  an  append.. .gclose  pair  of  calls.  All  x-y 
coordinate  arguments  should  be  fioating  point.  The  current  position  is  carried  across  a 
call  to  gclose,  so  segments  do  not  have  to  start  with  a  move  or  moveto.  The  initial 
value  of  the  current  position  just  after  calling  init  (VI),  is  (0.,  0.). 

The  following  three  routines  cause  the  current  state  (i.e.,  colour,  Iwidth,  intensity,  x 
and  y  position,  window  and  viewport)  to  be  saved  or  restored  from  an  internal  GPAC 
stack.  There  is  also  a  routine  to  initialize  these  variables. 

pushstatefj  —  The  current  state  is  saved  oh  the  stack.  Maximum  stack  depth  is 
reached  when  GPAC  can  not  dynamically  allocate  any  more  core. 

popatateCj  —  The  top  entry  of  the  state  stack  is  used  to  reset  the  state  variables. 
Popping  from  an  empty  stack  is  an  error. 
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initatatefy)  --  All  state  variables  are  reset  to  their  initial  values  and  the  state 
stack  is  cleared. 


Trans  formations 


The  transformation  capabilities  of  GPAC  are  intended  to  allow  the  user  to: 

1.  --  Define  pictures  in  local  coordinates  and  have  them  scaled,  rotated  and 

translated  before  they  are  displayed. 

2.  --  Define  large  pictures,  too  big  to  fit  on  the  screen  at  once,  and  to  window  in 

on  sections,  enlarging  if  desired. 

3.  --  Write  programs  which  are  not  affected  by  the  different  screen  characteris¬ 

tics  of  each  output  device. 

4.  ~  Write  programs  which  deal  with  a  coordinate  system  suited  to  their  applica¬ 

tion  rather  than  one  which  fits  on  the  output  device. 

GPAC  allows  the  user  to  define  his  pictures  in  the  Real  Cartesian  Coordinate  system  and 
to  look  through  a  window  onto  this  space.  This  rectangular  window  and  the  space  onto 
which  it  maps  may  use  a  coordinate  system  entirely  different  from  that  of  the  output 
device’s  screen  or  page.  Normally  the  window  is  defined  before  opening  segments  on 
which  the  window  operates.  When  graphical  primitives  are  added,  GPAC  transforms 
their  positions  according  to  user  specified  translations,  scales  and  rotations,  then  clips 
away  everything  lying  outside  the  window  and  then  transforms  the  remaining  onto  a 
portion  of  the  screen— the  viewport.  The  clipping  and  window-viewport  operations  on 
picture  segments  only  apply  when  a  segment  is  being  created.  Changing  the  window  or 
viewport  will  only  affect  subsequent  graphical  primatives,  not  ones  already  defined. 

The  routines  translate,  scale  and  rotate  cause  the  x-y  positions  of  graphical  primitives 
to  be  transformed  in  the  user  coordinate  system  before  they  are  clipped  agednst  the 
window.  GPAC  maintains  a  Current  Transformation  Matrix  (CTM)  to  be  applied  to  each 
coordinate  pair.  It  is  initially  the  identity  matrix  (i.e.,  no  transformation  at  all).  Each 
call  to  one  of  these  routines  will  cause  the  CTM  to  be  postmultiplied  by  the  transforma¬ 
tion  matrix  specified  by  the  call.  Multiple  calls  will  have  the  effect  of  concatenating  the 
transformations  together  in  the  order  they  were  specified.  Changing  the  CTM  by  cal¬ 
ling  one  of  these  routines  will  also  apply  the  new  transformation  to  the  current  beam 
position.  Arguments  to  these  routines  are  of  type  double  floating  point. 

translatefdr,  dy)  —  This  routine  causes  all  the  following  graphical  primitives  to 
be  translated  by  (dx,  dy).  The  CTM  is  multiplied  by  the  matrix  specifying 
a  translation  through  (dx,  dy). 

scalefsr,  sy)  —  All  subsequent  graphical  primitives  will  be  scaled  by  sx  in  the  x 
and  sy  in  the  y  directions.  Note  that  all  scaling  occurs  about  the  origin  of 
the  user  coordinate  system  (0.0,  0.0). 
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rotate(^radian.s^  —  A  rotation  of  all  subsequent  graphical  primitives  by  the  indi¬ 
cated  number  of  radians  about  the  origin  of  the  user  coordinate  system 
(O.O,  O.O)  is  requested.  The  sequence  of  calls,  traiislate(— xO,  — yO); 
rotate(ani^le);  translate(xO,  yO);  will  cause  rotation  about  a  specific  point 
(xO,  yO). 

If  it  is  necesasry  to  perform  arbitrary  affine  transformations,  the  following  routine  is 
available. 

multmatf --  Multmat  causes  the  CTM  to  be  postmultiplied  by  the  matrix 
contained  in  arr.  The  argument,  arr,  is  a  3  by  2  double  precision  array, 
which  has  an  implicit  last  column  of  [  0.0  0.0  1.0].  Since  the  CTM  is  a  3 
by  3  array,  multiplying  arr  and  it  together  will  again  yield  a  3  by  3  array. 

It  may  be  useful  to  premultiply  the  CTM  (i.e.,  specify  the  transformations  in  reverse 
order)  so  the  routines  posttranslatea  postacale  and  postrotate  are  available.  They  take 
exactly  the  same  arguments. 

The  following  routines  cause  the  CTM  to  be  saved  on  or  restored  from  an  internal  GPAC 
stack.  There  is  also  a  routine  for  reinitializing  the  CTM. 

pushmatf'J  —  A  copy  of  the  CTM  is  pushed  onto  an  internal  GPAC  stack.  The  max¬ 
imum  stack  depth  is  met  when  GPAC  cem  no  longer  dynamically  allocate 
any  core. 

popmatf))  —  The  topmost  entry  on  the  internal  stack  is  removed  and  used  to 
replace  the  CTM.  Popping  from  an  empty  stack  is  an  error. 

mitmat(9  ~  All  entries  on  the  internal  matrix  stack  are  removed  and  the  CTM  is 
set  to  the  identity  matrix  when  initmat  is  called. 

The  following  two  routines  are  used  to  define  a  window  onto  the  user  coordinate  space 
and  a  viewport  onto  the  screen,  into  which  all  the  information  in  the  window  is  mapped. 

windowfarcTifT",  ycntr,  xsize,  ysize)  —  Window  creates  the  rectangular  window  with 
centre  (xcntr,  ycntr),  half  the  length  of  the  horizontal  side,  xsize,  and 
half  the  length  of  the  vertical  side  length,  ysize.  All  graphical  primitives 
lying  outside  the  window  are  clipped  away  and  thus  do  not  appear  on  the 
screen.  For  primitives  that  cross  the  window  boundary,  only  the  parts 
interior  to  the  window  will  be  visible.  The  parameters  to  this  routine  are 
in  the  user  coordinate  system  and  are  thus  double  floating  point.  Note 
that  these  parameters  are  in  absolute  user  coordinates  (i.e.,  the  current 
transformation  is  not  applied  to  them).  The  default  setting  of  the  window 
is  specified  by  the  following  arguments  (511.5,  511.5,  511.5,  511.5). 

Yiewportf xcntr,  ycntr,  xsize,  ysize)  —  The  viewport  is  the  portion  of  the  output 
screen  onto  which  the  window  is  mapped.  The  arguments  define  a 
viewport  on  the  screen,  where  the  centre  and  sizes  of  the  viewport  are 
specified  in  a  1.0  by  1.0  viewport  coordinate  space.  For  each  device  the 
largest  square  that  can  be  drawn  in  the  centre  of  the  screen  is  defined  to 
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have  corner  coordinates  (0.0,  0.0)  and  (1.0,  1.0)  in  the  viewport  coordi¬ 
nate  space.  Since  the  largest  square  in  the  centre  of  the  screen  may  not 
cover  the  entire  screen  (if  it  is  not  square),  the  rest  of  the  screen  may  be 
accessed  using  coordinates  with  negative  values  or  values  greater  than  1. 
Note  however  that  this  is  a  dangerous  and  device  dependent  use  of 
viewport.  To  achieve  the  largest  square  in  the  centre  of  the  screen  as  the 
viewport,  the  call  to  viewport  should  be:  viewport(.5,  .5,  .5,  .5);.  Appendix 
V  lists  the  limits  of  the  viewport  coordinate  space  for  each  device. 
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Section  III  -  Graphical  Input 


Input  routines  have  been  implemented  for  both  the  tek  and  gw  devices  (See  device 
descriptions  in  Appendix  V). 

The  input  scheme  revolves  around  the  concept  of  an  event.  Events  are  generated  by 
certain  user  interactions  happening  at  the  various  input  devices.  At  any  time  in  his 
program,  the  user  can  activate  events  he  wishes  to  allow  and  deactivate  those  he 
wishes  to  disregard.  The  possible  events,  patterned  after  the  digitizing  tablet  with  its 

Z — axis  button  and  3  button  box,  are  shown  in  the  following  table.  The  event type 

column  specifies  the  numeric  values  used  to  refer  to  the  events.  The  gw  and  tek 
columns  indicate  whether  the  event  is  available  on  that  device. 


Event  1 

L 

Event_type  | 

.  1 

gw  j 

1 

tek 

1 

Interval 1  | 

0  1 

1 

yes  1 

no 

Intervals  | 

1  1 

yes  1 

no 

Intervals  | 

2  1 

yes  1 

no 

Inking  | 

3  1 

yes  1 

yes 

Timeout  | 

4  1 

yes  1 

no 

Tty  1 

5  1 

yes  1 

yes 

2L_axis_down  | 

6  1 

yes  1 

yes 

Z_axis_up  1 

y  1 

yes  1 

yes 

Button  l_down  | 

8  1 

yes  1 

yes 

Button  l_up  1 

9  1 

yes  1 

yes 

Button2_down  | 

10  1 

yes  1 

yes 

Button2_up  1 

11  1 

yes  1 

yes 

Button  3_down  | 

12  1 

yes  1 

yes 

Button3__up  1 

13  1 

yes  1 

yes 

Range_out  | 

14  1 

yes  1 

yes 

Range_in  | 

15  1 

yes  1 

yes 

When  using  the  tablet,  the  down  and  up  events  are  caused  by  the  user  pressing  and 
releasing  the  various  buttons  on  the  tablet  cursor.  The  Range-out  event  occurs  when 
the  tablet  tries  to  read  the  stylus  position  and  it  is  not  in  range  (approx.  1/4  inch 
above  surface  and  off  the  sides).  The  Range-in  event  occurs  when  the  stylus  comes 
back  into  range.  The  Tty  event  is  generated  when  the  user  types  something  at  the  ter¬ 
minal.  By  setting  the  terminal  in  raw  mode  or  buffered  mode,  the  event  can  be  trig¬ 
gered  by  every  character  or  only  by  whole  lines.  The  Interval  events  are  generated 
every  ‘'delta_t”  milliseconds,  where  “deltEL_t’‘  is  specified  in  the  activate  call  for  the 
event.  The  user  can  have  up  to  three  different  interval  timers  causing  events  at  one 
time.  The  Timeout  event  is  caused  if  no  user  action  has  taiken  place  after  the  last  event 
within  "timeout—intervar'  milliseconds.  The  “timeout_intervar’  is  specified  in  the 
activate  call. 
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On  the  Tektronix  the  buttons  of  the  stylus  are  simulated  with  different  keys  on  the 
terminal’s  keyboard.  When  the  program  performs  a  gctevent  call  the  crosshairs  of  the 
terminal  aire  displayed  and  the  user  can  modify  the  position  of  their  intersection  by 
manipulating  the  thumbwheels  at  the  side  of  the  keyboard-  When  the  position  is 
correct  the  user  now  indicates  which  event  he  wishes  to  generate  by  first  pressing  the 
escape  key  (i.e.,  ESC)  of  the  terminal  followed  by  another  key  indicating  the  desired 
event.  Before  pressing  the  second  key,  the  user  should  wait  for  the  crosshairs  to  reap¬ 
pear.  The  following  table  relates  the  events  with  their  corresponding  characters. 


EVENT 

1  Tektronix  Character  Sequence 

J 

Z_axis_down 

1  ESC 

z 

Z_axis_up 

1  ESC 

X 

Button  l_down 

1  ESC 

1 

Button  l_up 

1  ESC 

q 

Button2_down 

1  ESC 

2 

Button  2_up 

1  ESC 

w 

Button3_down 

1  ESC 

3 

Button3_up 

1  ESC 

e 

Range_out 

1  ESC 

r 

Range _ in 

1  ESC 

t 

To  generate  normal  Tty  events  on  the  Tektronix,  the  characters  themselves  aure  tjrped 
mth  no  initial  escape  character. 

The  inking  event  is  defined  by  the  following  table: 


ACTIONS 

1 

1  EQ  SPACE 
.1 

MODES 

EQ  TIME 

POINT 

BEGIN 

1  button  #3 

1  or 

1  Z_down 

1  or 

1  button  ^  1 

1  or 

1  button  #2 

1 

button  ^3 
or 

Z—down 

or 

button  #1 
or 

button  #2 

button  #3 
or 

2L.down 

or 

button  #1 
or 

button  5^2 

START 

1 

1  Z_down 

1 

ZL.dowTi 

button  #1 

STOP 

CSl 

1 

c 

Z.-UP 

2L_up 

CONTINUE 

1 

1  button  #1 

1 

button  #1 

Z_dowTi 

CLEAR 

1 

1  button  #2 

1 

button  #2 

button  #2 

END 

1 

1  button  #3 

button  #3 

button  #3 
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or 

Proximity 

or 

Timeout 

or 

Z_up 


or 

Proximity 

or 

Timeout 

or 

Z_up 


or 

Proximity 

or 

Timeout 

or 


Z_up 


To  initiate  inking,  the  user  must  perform  the  BEGIN  action  (i.e.,  depress  button  3  or 
whatever  interaction  is  in  effect),  whereupon  all  buttons  perform  the  actions  indicated 
in  the  table.  The  START  action  causes  a  new  curve  to  be  started  and  the  STOP  action 
terminates  the  current  curve.  Thus  when  in  equal-space  or  equal-time  modes,  an  ink 
trail  will  be  left  while  the  Z-axis  button  is  depressed.  The  CONTINUE  action  will  cause 
the  next  START  action  to  continue  from  the  endpoint  of  the  last  curve  rather  than 
starting  a  new  one.  Between  CONTINUE  and  STOP  actions,  a  rubber  band  line  follows 
the  cursor  when  inking  in  point  mode.  The  CLEAR  action  erases  all  curves  that  have 
been  drawn  during  the  current  inking  event.  Once  inking  is  initiated  only  the  END 
action  will  cause  the  inking  event  to  be  terminated,  and  control  returned  to  the  user. 
The  user  program  has  the  ability  to  specify  which  start  and  end  conditions  are  to  be 
used. 


The  inking  event  has  higher  priority  than  other  events.  Thus  if  the  user  has  activated 
the  Z_axis__down  event  and  the  inking  event  with  Z_axis_down  as  the  BEGIN  action, 
the  inking  event  is  always  initiated  whenever  the  user  depresses  the  Z_axis_button. 

On  the  tek  the  ’z’,  ’2’  and  ’3’  keys  are  used  for  the  Z-axis  and  buttons  1,  2  and  3 

during  inking.  The  BEGIN  action  is  an  “ESC  3’’.  “ESC  2”.  “ESC  1”.  or  “ESC  z“  charac¬ 
ter  combination  as  above.  Only  point  mode  is  available  on  the  tek  and  it  has  no  rubber 
banding.  Once  inking  has  begun,  hitting  the  ’z‘  character  will  fix  the  next  point  at  the 
intersection  of  the  cross  hairs  and  a  line  will  be  drawn  joining  it  to  the  last  point.  The 
space  bar  (i.e.,  blank)  performs  exactly  the  same  function  as  the  ’z’  key  when  inking  is 
in  progress.  The  ’1’  key  initiates  a  new  curve,  the  ’2’  key  erases  the  current  ink  trail, 
and  the  '3’  or  ’x’  keys  are  used  to  terminate  inking.  (Note  the  proximity  or  timeout 
mechanisms  are  not  implemented  for  the  tek.) 

The  slider  box  is  also  interfaced  to  GPAC.  It  consists  of  two  touch  sensitive  sliders  and 
four  two  position  buttons.  The  following  events  can  be  activated  for  the  sliders. 


Event  1 

1 

Event_type  I 

gw  1 

L 

tek 

1 

Shut] _ down  I 

1 

17  1 

1 

yes  1 

no 

Sbutl_up  1 

18  1 

yes  1 

no 

Sbut2_down  1 

19  1 

yes  1 

no 

Sbut2_up  1 

20  1 

yes  1 

no 

Sbut3_down  I 

21  1 

yes  1 

no 

Sbut3_up  1 

22  1 

yes  1 

no 

Sbut4;_down  I 

23  1 

yes  1 

no 

Sbut4_up  1 

24  1 

yes  1 

no 

Ssldl  1 

25  1 

yes  1 

no 

Ssld2  1 

26  1 

yes  1 

no 
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Ssldl_down  | 

27  ( 

yes 

1 

no 

Ssldl _ up  1 

26  1 

yes 

1 

no 

Ssld2_down  j 

29  1 

yes 

1 

no 

Ssld2_up  1 

30  1 

yes 

1 

no 

The  button  down  and  up  events  are  generated  when  the  slider  box  buttons  are  pushed 
and  released.  The  slider  down  and  up  events  are  generated  when  the  sliders  are 
touched  and  released.  The  slider  events  (e.g.,  Ssldl)  are  generated  when  the  sliders 
are  moved  up  or  down. 

The  implemented  graphics  input  routines  are: 

activate('ei»eni_iype,  arpj  —  Activate  causes  one  of  the  events  listed  above  to  be 
activated.  Event_type  specifies  which  event  is  to  be  allowed  to  occur, 
and  arg  is  an  eirgument  specifying  the  time  in  milliseconds  connected 
with  the  event.  Thus  arg  is  only  meaningful  for  the  Interval  and  Timeout 
events. 

deactivate —  Deactivate  informs  the  system  the  event  indicated  by 
event _ type  is  now  to  be  ignored. 

inkpanns fmode,  sample_interval,  start_end^cond,  timeout^intrvl)  —  This  rou¬ 
tine  specifies  the  parameters  for  subsequent  calls  to  ink  and  for  inking 
events.  Inkparms  is  a  nop  when  using  the  tek,  since  only  point  mode  is 
edlowed.  Possible  modes  of  inking  are: 

0]  equal-space  -  0 

1]  equal-time  -  1 

2]  point  or  rubber-beind  -  2 

For  equal-space  mode  sample^interval  is  the  minimum  number  of  screen 
units  that  the  stylus  must  be  moved  before  a  new  point  is  added  to  the 
curve  being  drawn.  In  equal-time  mode  it  is  the  time  in  milliseconds 
between  sampling  the  tablet  for  a  new  point  to  add  to  the  curve.  No 
meaning  is  attached  to  it  in  point  mode. 

StaTt_end_cond  specifies  the  actions  which  are  to  signal  the  start  and 
end  of  inking.  The  implemented  end  conditions  are: 

O]  button  3-0 

1]  outofrange  -  1 

2]  timeout  -  2 

3]  Z  up  -  3 
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Possible  start  conditions  are: 

0]  button  3  down  -  0000 

1]  z  axis  down  -  0400 

2]  button  1  down  -  01000 

3]  button  2  down  -  02000 
4}  button  3  down  -  04000 

The  staTt^end_cond  parameter  provided  to  in]i;_pann9  is  the  “inclusive 
or"  of  the  desired  start  and  end  conditions. 

The  final  parameter,  timeout^intrvl,  is  the  number  of  milliseconds  the 
system  will  wait  for  further  inking  before  ending  the  inking  event,  if 
timeout  is  the  end^cond.  Using  timeout  for  both  inking  termination  and 
as  an  event  is  not  allowed. 

getevent(9  —  The  user  program  is  set  to  sleep  until  the  next  interaction  by  the 
user  occurs.  The  interactions  that  can  cause  getevcnt  to  return  are 
those  events  that  the  user  program  has  activated. 

Getevent  returns  a  pointer  to  a  structure  of  the  form: 

struct  event 

i 

int  type; 
int  x; 
int  y; 

int  status; 

struct  curves  *ink_«ptr; 

!.■ 

The  event  type  Tvill  be  one  of  the  above  events  that  have  been  activated.  X 
is  the  tablet  x  position  in  screen  coordinates  at  the  time  of  the  event,  and 
y  the  y  coordinate.  To  transform  these  points  to  user  coordinates. 
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screentouser,  should  be  used. 

Status  is  a  field  used  to  inform  the  user  in  detail  the  current  state  of  the 
device  from  which  the  event  originated.  If  the  event  type  originated  from 
the  gw  tablet  interface  (i.e.,  event  types  0  to  15  on  the  gw),  the  informa¬ 
tion  in  status  can  be  described  by  the  following  C  structure: 

struct  status 

i 

int  z_axis:  1; 
int  buttn_l:  1; 

int  buttn _ 2:  1; 

int  buttn _ 3:  1; 

int  :  1; 

int  :  1; 

int  :  1; 

int  z_axis__transition:  1; 

int  buttonl_transition:  1; 

int  button2_transition;  1; 

int  button3_transition:  1; 

int  :  1; 

int  :  1; 

int  out  of  range:  1; 

int  overrun:  1; 

int  error:  1; 

(This  bit-field  syntax  is  from  the  Version  7  C  compiler).  The  error  bit  is 
set  if  either  the  overrun  or  outofrange  bits  are  set.  Note  that  the  error 
bit  is  the  most  significant  bit  (i.e.,  bit  15)  if  this  structure  is  not  used. 
The  overrun  bit  is  set  when  too  many  interrupts  are  occuring  for  UNIX  to 
handle  (this  should  never  happen!!).  The  outofrzinge  bit  is  on  if  the  tablet 
stylus  is  more  than  1/4  inch  above  or  outside  the  recording  surface  of  the 
tablet.  The  transition  bits  are  on  if  during  the  interval  between  the  last 
two  tablet  interrupts,  the  indicated  button  went  from  the  released  to  the 
depressed  state.  The  other  button  bits  indicate  the  state  of  the  button  at 
the  last  interrupt  (0  for  released  and  1  for  depressed).  For  the  tek, 
status  contains  the  character  the  user  hit  that  caused  the  event  to  be 
generated. 

The  user  is  responsible  to  read  his  characters  if  a  Tty  event  occurs.  If  he 
does  not  read  the  characters,  the  event  will  be  regenerated  every  time 
getevent  is  called  until  he  does.  There  is  currently  a  discrepancy 
between  the  gw  and  tek  handling  of  tty  events.  The  above  refers  to  the  gw 
version.  On  the  tek,  raw  mode  should  not  be  used.  Also  the  first  charac¬ 
ter  typed  is  read  by  GPAC  and  put  in  the  status  field  of  the  event  struc¬ 
ture.  The  user  must  read  the  remaining  characters  until  a  newline  is 
encountered.  If  he  does  not  read  the  characters  when  so  informed,  the 
tek  getevent  will  not  repeat  the  event  as  the  gw  version  does. 


-14- 


Graphical  Input 


GPAC  Users*  Manual 


Ink — ptr  is  a  pointer  to  the  following  series  of  structures  describing  the 
coordinates  of  the  points  in  the  ink  buffer  if  the  event  type  is  Inking.  The 
structures  used  are: 


struct  xypair 

i 

int  xx; 
int  yy; 

i: 

struct  curve 

i 

int  npts; 

struct  xypair  pts[  /*  npts  •/  ]; 

): 

struct  curves 

s 

int  ncurves; 

struct  curve  *c_ptr[  /*  ncurves  •/  ]; 

i: 

The  contents  of  these  structures  will  be  altered  on  following  calls  to  input 
routines  so  all  information  desired  must  be  saved  by  the  user.  Both  ink 
and  getevent  inform  the  user  program  that  the  ink  buffer  is  full  by 
returning  a  negative  inking  type  (i.e.,  -3)  in  the  event  structure.  The 
points  returned  in  the  inking  structures  are  still  correct  —  they  are  just 
not  complete. 

If  a  slider  event  is  generated,  exactly  the  same  format  of  structure  is 
returned.  The  x  field  contains  the  current  position  of  slider  one  and  the  y 
field  contains  slider  two’s  position.  The  slider’s  initial  position  is  set  with 
the  slideinit  routine  described  following.  Moving  a  slider  up  increments 
its  position.  Moving  it  down  decrements  its  position.  The  status  field  for 
slider  events  can  be  described  in  more  detail  by  the  following  structure: 


struct  status 

i 

int  butl:  1 
int  but2:  1 
int  but3:  1 
int  but4:  1 

The  ink  ptr  is  meaningless 


/♦  Set  to  1  if  depressed  */ 
/*  Set  to  1  if  depressed  */ 
/*  Set  to  1  if  depressed  */ 
/*  Set  to  1  if  depressed  */ 


for  slider  events. 


inVf)  ~  Ink  calls  the  operating  system  to  do  inking  for  you.  The  BEGIN  action  of 
the  inking  event  is  not  required  to  initiate  inking  when  ink  is  called.  Oth¬ 
erwise  inking  is  performed  in  the  same  way  as  in  the  inking  event.  The 
ink  routine  is  used  when  the  next  user  interaction  must  be  inking  and  so 
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the  generality  of  getevent  is  not  needed.  Ink  returns  a  pointer  to  an 
event  structure,  as  defined  above  in  getevent.  Inking  must  still  be 
activated  via  activate  to  make  use  of  ink. 

clearinkf^  —  Clearink  causes  the  ink  buffer  to  be  cleared  and  removed  from  the 
screen. 

invisinkf^  —  Invisink  causes  all  subsequent  inking  to  be  invisible  on  the  display 
screen.  The  inked  points  are  still  returned  to  the  user  program  *  you  just 
cannot  see  them. 

visinkf^  —  Visink  turns  ink  trails  back  on.  This  is  the  default  mode. 

readpositionfj  --  The  position  and  status  of  the  tablet  are  obtained  immediately 
without  wedting  for  a  user  interaction  and  placed  in  a  structure  of  the 
type  event  described  above.  A  pointer  to  this  structure  is  then  returned 
to  the  user.  Note  that  no  readposition  event  needs  to  be  activated.  Read- 
position  is  GPAC’s  mechanism  for  polling  the  tablet.  On  the  tek,  a  user 
interaction  is  required  before  readposition  will  return.  Any  character  hit 
when  the  cross  hairs  are  displayed  will  cause  readposition  to  return  with 
the  cross  hairs’  position  as  well  as  the  character  hit. 

trackf'se5rmenf_ntim6erj  —  The  indicated  picture  segment  is  used  as  the  track¬ 
ing  cross  from  now  until  the  next  call  to  track  or  untrack  or  until  a  seg¬ 
ment  is  tracked  as  a  result  of  a  call  to  cursor  described  below.  The  initial 
visible  point  of  the  segment  is  the  point  that  will  be  tracked.  Track  will 
post  the  segment  if  it  is  not  posted  already.  Tracking  is  not  available  on 
the  tek. 

untrackfj  --  The  segment  being  tracked  is  not  tracked  any  more.  The  segment 
is  unposted. 

cursorfmodc,  segment _rvambeT)  —  In  highly  interacive  graphics  programs,  the 
user  should  always  be  visually  informed  as  to  what  state  the  program  is 
currently  in  and  of  any  state  changes.  Because  GPAC  runs  in  a  time¬ 
sharing  system,  the  time  between  when  a  user  generates  an  event  (by 
pushing  a  button  for  example)  and  when  the  program  starts  executing 
Eind  is  informed  of  the  event  can  at  times  of  peak  load  be  up  to  5  seconds 
or  more.  GPAC  can  arrange  to  have  the  tracking  cross  automaticaly 
switched  at  the  point  in  time  when  the  operating  system  detects  the 
event.  A  call  to  cursor  with  mode==0,  informs  GPAC  which  segment  to 
post  and  track  whenever  an  event  is  recognized. 

The  getevent  mechanism  allows  inking  to  begin  via  user  interaction. 
There  is  a  mechanism  via  cursor  to  have  a  user-defined  inking  cursor  be 
tracked  whenever  the  inking  event  is  in  progress.  This  is  important  as 
there  is  no  other  way  of  informing  the  user  that  he  has  entered  the  inking 
state.  A  call  to  cursor  with  mode==l,  informs  GPAC  which  segment  is  to 
be  the  inking  cursor.  The  system  will  automatically  post  this  segment 
and  track  it  whenever  any  subsequent  inking  events  are  begun. 
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The  curaor  routine  does  not  cause  the  tracking  crosses  to  change 
immediately,  it  just  saves  the  information  away  to  use  when  an  event  or 
inking  occurs.  Whenever  the  event  or  inking  cursor  is  posted,  the  current 
tracking  segment  is  unposted.  To  regain  the  original  tracking  cross, 
track  must  be  called  again.  If  a  user  does  not  call  cursor,  tracking  seg¬ 
ments  are  not  changed  when  events  or  inking  occur. 

recogmze(^infc_6ii^er__pomferj  —  Recognize  is  a  routine  which  will  take  an  ink 
buffer  as  returned  with  an  inking  event  and  try  to  recognize  it  as  a  char¬ 
acter.  The  user  must  previously  have  called  setrecognizer  to  tell  GPAC 
which  file  to  use  as  the  character  dictionary.  Recognize  returns  a  pointer 
to  a  structure  of  the  following  form: 

struct  rec^info 

I 

int  id; 

Lnt  xO,  yO; 
int  dx,  dy: 
int  pvector[4]; 
struct  curves  *sketch; 


Id  is  the  ASCII  representation  of  the  character  recognized  (0  for  none 
recognized).  XO  and  yO  are  the  x  and  y  coordinates  of  the  lower  left 
corner  of  the  minimum  enclosing  rectangle  of  the  user  sketch  in  screen 
coordinates.  Dx  and  dy  are  the  dimensions  of  the  minimun  enclosing  rec¬ 
tangle.  Pvector  is  an  array  of  the  properties  assigned  to  the  sketch.  The 
individual  elements  represent: 

pvector[0]  —  number  of  strokes-1 
pvector[l]  "  region#  of  the  first  point 
of  first  stroke 

pvector[2]  —  region#  of  last  point 
pvector[3]  —  number  of  crossings  into 
and  out  of  central  region 

Sketch  is  a  pointer  to  a  copy  of  the  user  sketch.  The  maximum  values  for 
each  property  are  9,  4,  4,  14  respectively. 

9etrecogiiizer(^j^Je_nameJ  —  This  routine  indentifies  to  GPAC,  the  character  dic¬ 
tionary  to  be  used  by  the  recognize  routine.  The  file  must  have  been 
created  by  the  Character  Recognizer  Trainer  (Appendix  II).  The  last  two 
characters  of  file_name  must  be  “.r”.  If  the  file  does  not  exist  the  recog¬ 
nizer  is  initialized  with  a  null  dictionary.  Setrecognizer  returns  -1  if  the 
dictionary  file  is  invalid  and  0  otherwise.  If  invalid  any  subsequent  calls  to 
the  recognizer  routines  are  invalid. 
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slideinitfsi/pos,  sl2pos)  —  This  routine  is  used  to  initialize  the  slider  and  to  set 
its  current  position  to  the  indicated  values.  The  arguments  are  integers. 
Slideinit  must  be  called  before  any  slider  events  are  activated.  Slideinit 
may  also  be  called  at  any  time  to  reset  the  current  position  to  any  values. 

readsliderf'j  --  The  current  status  and  position  of  the  sliders  is  returned  in  an 
event  structure. 
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Section  IV  -  Film  Routines 


The  routines  in  this  section  are  used  for  film  creation.  A  playback  file  is  created  which 
can  be  then  played  back  at  accurate  speed  (see  prev  and  playback  in  Appendix  II)  or 
sent  to  the  Calcomp  Microfilm  plotter  (see  plot  in  Appendix  II). 

beginfilmf file_nanie )  —  This  routine  initializes  a  file  provided  by  the  user  to  con¬ 
tain  the  raw  playback  display  files.  The  argument  is  a  string  containing 
the  file  name. 

endfilmfj  --  Causes  all  post  processing  of  the  film  file  to  be  done.  The  total 
number  of  frames  in  the  file  are  returned. 

fr sme( duration)  —  Frame  defines  the  frames  in  the  film  to  which  subsequent 
include  calls  add  segments.  The  frame  counter  is  set  to  one  at  the  call  to 
beginfilm  and  each  call  to  frame  increments  it  by  the  duration,  an 
integer.  Frame  always  returns  the  current  frame  counter  after  it  is 
incremented.  For  example  to  include  segments  4  and  5  in  the  first  3 
frames  and  1,  2  and  7  in  frames  4  to  7,  the  follomng  calls  should  be  made: 

frame(3): 

include(4); 

include(5); 

frame(4); 

include(l); 

include(2): 

mclude(7); 

includefsepmeni _ number)  —  This  routine  includes  the  segment  indicated  in  the 

current  frames  as  defined  in  frame.  The  only  requirement  about  the  seg¬ 
ment  is  that  it  exists. 
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Section  V  -  Standard  Format 


Standard  format  -  a  fairly  compact  and  easy  to  manipulate  encoding  of  graphical 
images  -  is  meant  to  be  the  common  factor  in  a  complex  graphics  environment.  All 
methods  of  generating  pictures  should  be  able  to  produce  a  standard  format  output 
and  all  methods  of  displaying  pictures  should  be  able  to  handle  a  standard  format 
input.  This  section  does  not  describe  the  actual  format  {see  Appendix  II  and  man  5 
gsformat),  but  gives  a  list  of  routines  available  from  GPAC  to  create  or  read  it. 

sfinterpf'bu/pj  --  This  routine  interprets  a  standard  format  file  and  calls  the 
appropriate  GPAC  routines.  Standard  Format  is  described  in  Appendix  II. 
The  user  must  have  a  segment  open  before  calling  sfinterp.  The  argu¬ 
ment  is  a  pointer  to  a  getc  buffer  (See  UNIX  Programmer’s  Guide  Section 
3).  The  file  must  already  be  open  and  the  Standard  Format  magic  number 
stripped  off.  Sfinterp  will  return  when  it  reaches  an  error  (return  value  of 
-1),  when  it  reaches  an  endoframe  (return  value  of  1),  or  when  it  reaches 
an  endodata  (return  value  of  0).  Repeated  calls  to  sfinterp  will  decode 
multiple  frames  within  a  file.  It  is  the  user’s  responsibility  to  close  and 
post  the  segment  in  which  sfinterp  puts  the  graphical  primatives. 
Sfinterp  does  not  directly  call  the  appropriate  GPAC  routine.  Instead  it 
calls  a  series  of  other  routines  which  then  call  GPAC.  This  enables  the 
user  to  define  his  own  versions  of  the  intermediate  routines  and  access 
the  data  as  sfinterp  decodes  it.  The  complete  list  of  intermediate  rou¬ 
tines  is: 

sfmoveto,  sfiineto,  sfchars,  sffillbegin,  sffillend,  sfintens,  sfcolour, 
sflwidth 

The  arguments  to  each  of  these  routines  is  exactly  the  same  as  the 
corresponding  GPAC  routine.  The  default  versions  of  these  routines  in 
GPAC  just  call  the  appropriate  real  GPAC  routine.  The  Standard  Format 
commands  clearscreen,  clearrectangle,  setrgb,  enclosingrectangle,  and 
setfont  are  treated  as  nops.  Characters  are  drawn  using  chars.  Note  that 
sfinterp  will  produce  graphical  primatives  in  the  coordinate  space 
bounded  by  0.0  and  4095.0  in  both  x  and  y  directions.  Windows  and 
viewports  should  be  set  accordingly. 

snapfdemce_^na7n€j  --  The  snap  routine  is  used  to  transfer  the  current  screen 
image  to  another  device.  Possible  devices  to  snap  to  eire  those  imple¬ 
mented  as  GPAC  devices  (See  Appendix  V)  and  ’'vp",  the  Versatec  Printer 
Plotter.  When  snapping  to  another  terminal  (i.e.,  gw,  cv  or  tek),  the 
transfer  takes  place  immediately  if  the  de>nce  is  available.  Subsequent 
snaps  will  replace  what  is  currently  on  the  device  with  the  new  screen 
image.  If  the  device  is  not  available,  snap  will  return  an  error.  For  spool¬ 
ing  devices  (i.e.,  vp),  the  screen  image  is  sent  to  the  spooler  for  plotting 

whenever  the  device  becomes  available.  If  the  device _ name  is  '’null''  or 

unknown  to  snap,  a  file  is  created  in  the  current  directory  containing  the 
screen  image  in  standard  format.  The  file  is  called  "snap. out"  if  the 
device — name  is  "null";  otherwise  the  string  device _ name  is  used  as  the 
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file’s  name. 

mterp(^jTJe_name^  —  The  file  indicated  is  read  and  instructions  in  it  are  decoded 
into  GPAC  calls  which  are  executed.  Files  of  this  sort  are  created  by 
using  the  dummy  GPAC  library  described  in  Appendix  II  under  build 
interp.  The  GPAC  routines  callable  from  interp  files  are: 

gopen,  gclose,  post,  unpost,  append,  delete,  moveto,  move,  lineto, 
line,  chars,  intens 

Interp  can  be  very  useful  in  programs  dealing  with  large  numbers  of 
static  segments.  Instead  of  having  code  in  the  program  to  create  all  the 
segments,  you  write  another  program  to  generate  an  interp  file  and  call 
interp  to  display  them  on  the  screen. 
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Section  VI  -  Initialization  and  Termination 


Before  any  GPAC  routines  are  called,  it  is  necessary  to  initialize  GPAC.  When  the  user 
program  is  finished  with  graphics  it  is  necessary  to  terminate  GPAC.  The  following  rou¬ 
tines  are  provided  for  these  purposes. 

initf disp_Jile^size,  ink_J)uf_size,  TiU7n_segs,  font)  —  Init  causes  GPAC  to  initial¬ 
ize  itself.  It  must  be  called  before  other  GPAC  routines  and  only  called 
once.  The  graphics  device  to  be  used  by  the  program  is  specified  when 
the  GPAC  program  is  compiled.  Possible  devices  implemented  by  GPAC 
are: 


1.  gw  “  Graphic  Wonder 

2.  cv  —  Colour  Video 

3.  tek  —  Tektronix  4013 

4.  gt  -  DEC  Gt40 

5.  null  ~  A  fictitious  device  used  for  debugging  and  communicating 

to  other  graphics  devices  (e.g.,  Versatec  and  Microfilm). 

The  null  device  produces  standard  format  as  output. 

6.  gwfake  —  A  version  of  the  gw  device  that  does  not  display  infor¬ 

mation  on  the  display  screen. 

See  Appendix  V  for  a  complete  description  of  each  device. 

The  user  program  must  provide  a  workspace  for  GPAC  in  which  the 
display  file  can  be  constructed.  Modifications  to  UNIX  to  permit  graphics 
have  decreed  that  this  workspace  must  start  at  address  0  of  the  user’s 
data  space  and  that  its  size  be  in  multiples  of  IK  words.  The  method  of 
declaring  this  workspace  is  described  in  detail  in  Appendix  I.  Its  size  in 
words  is  the  first  argument  to  init.  A  rough  estimate  of  the  size  needed 
for  the  ordinary  GPAC  program  is  4096  words.  Another  measure  is  that 
approximatly  two  words  are  needed  for  every  vector  in  every  defined  seg¬ 
ment  (plus  about  10  words  of  fixed  overhead  per  segment).  If  the  user 
does  exhaust  all  his  workspace,  GPAC  will  produce  an  error  message  and 
the  user  will  have  to  rerun  his  program  with  a  larger  workspace  size. 

The  user  also  needs  to  notify  GPAC  as  to  whether  he  requires  the  input 
functions  eind  if  so  how  much  of  the  display  file  he  wants  to  allow  for  his 
ink  buffer  when  inking.  A  non-positive  second  argument  to  init  indicates 
that  no  input  functions  will  be  used.  Otherwise,  the  second  argument  is 
the  number  of  words  out  of  the  display  file  to  be  used  for  an  ink  buffer  (if 
no  inking  is  desired  but  other  input  routines  are,  give  this  parameter  a 
value  of  1).  GPAC  wiU  not  guarantee  this  size  of  ink  buffer  (it  will  use  the 
largest  contiguous  piece  of  core  it  has)  but  it  will  not  allow  more  than  this 
amount  to  be  used. 
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The  argument,  num^segs,  is  the  maximum  number  of  segments  the  user 
will  want  in  existence  at  any  at  one  time  throughout  his  program.  Seg¬ 
ment  numbers  specified  in  the  segment  handling  routines  must  be  in  the 
range  1  to  num^segs. 

The  final  argument  to  init  is  the  character  font  to  be  used.  This  is  a  char¬ 
acter  string  naming  the  font  file.  See  Appendix  V  for  a  list  of  fonts  avail¬ 
able  with  each  device.  Devices  having  no  fonts  or  only  a  hardware  font 
still  require  a  string  here,  preferably  a  valid  font  from  any  other  device  to 
make  changing  devices  easier. 

finishfj  —  This  routine  tells  GPAC  that  the  user  program  is  done.  It  should  be  the 
last  routine  called.  This  routine  is  especially  important  when  using  the 
tek  or  null  devices.  It  causes  various  internal  bookkeeping  to  be  cleaned 
up  and  output  flushing  to  be  done. 
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Section  VII  -  Auxiliary  Routines 


The  following  routines  are  useful  when  writing  graphics  programs. 

eTTOTs(code)  ~  GPAC  tries  very  hard  to  avoid  making  mistakes  in  following  user 
program  requests.  To  maiintain  this  high  standard,  it  is  sometimes  neces¬ 
sary  to  refuse  to  perform  some  action  the  user  requests.  This  might  be 
the  user's  fault  or  just  a  matter  of  running  out  of  resources.  To  inform 
the  user  when  this  happens  error  messages  are  printed  on  the  diagnostic 
output.  Appendix  IV  contains  a  cross  reference  of  GPAC  routines  versus 
possible  error  messages.  The  routine  errors  can  be  used  to  turn  this 
error  reporting  on  or  off.  A  code  of  0  turns  it  off;  a  1  will  turn  it  on.  The 
default  mode  in  on.  All  GPAC  routines  return  an  error  indicator  whether 
reporting  is  on  or  not.  A  returned  value  of  -1  from  any  GPAC  routine,  indi¬ 
cates  an  error  has  occured  and  any  other  return  indicates  no  error 
occured.  The  error  message  reporting  that  GPAC  has  run  out  of  core  in 
its  display  file  cannot  be  supressed. 

clearf9  ~  All  posted  segments  are  unposted  by  this  call. 

delrangefseymenf  / ,  segmerdZ)  --  Delrange  deletes  all  segments,  N,  that  exist  in 
the  range;  segmenti  <-1k<-=^segTneni2.  Errors  are  not  reported  for  seg¬ 
ments  that  do  not  exist. 

erasef'J  —  Erase  causes  all  existing  segments  to  be  deleted. 

nertavailsegfj  --  This  routine  returns  the  segment  number  of  a  nonexistent  seg¬ 
ment;  the  lowest  possible  segment  is  chosen.  If  all  segments  are  in 
existence,  -1  is  returned.  Nextavailseg  does  not  reserve  a  segment 
number,  so  multiple  calls  in  a  row  will  return  the  same  segment  number. 

define daeg('se£rmenf_num6erj  --  This  routine  returns  1  if  the  indicated  segment 
exists  and  zero  otherwise.  The  gopen  call  brings  a  segment  into  existence 
and  the  delete  call  ends  its  existence.  All  segments  are  initially  nonex¬ 
istent. 

postedseg(s<?5rmcn<_7iiim6erJ  —  This  routine  returns  1  if  the  indicated  segment 
is  posted  and  zero  otherwise. 

openedsegf^  --  This  routine  returns  to  the  user  the  segment  number  of  the 
currently  open  segment.  A  -1  is  returned  if  a  segment  is  not  open. 

icharsf' string)  —  The  specified  string  is  drawn  with  the  current  position  being  the 
starting  point  and  the  transformation  matrix  set  up  by  translate,  rotate, 
and  scale  applied  to  all  Lines  in  the  characters.  The  current  position  is 
changed  to  be  the  end  point  of  the  last  line  in  the  last  character.  The 
font  used  to  get  the  character  definitions  is  the  initial  font  specified  in 
the  init  call  (Section  VI).  The  ichars  routine  is  unfortunatly  much  more 
expensive  than  the  routine  chars. 
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icharsff' string,  font)  —  This  routine  is  exactly  like  ichars  except  a  different  font 
is  also  specified.  Font  is  a  character  string  specifying  any  of  the  charac¬ 
ter  fonts  described  in  Appendix  V. 

cjiTvetofnelements,  f array)  --  This  routine  is  a  special  purpose  curve  drawer. 
The  argument  farray  is  an  array  of  single  precision  floating  point  coordi¬ 
nate  pairs.  Curveto  does  a  moveto  to  the  first  point  and  then  connects 
the  remaining  pairs  via  lineto.  In  farray  there  are  nelements  coordinate 
pairs.  The  first  point  has  x-y  coordinates  farray[0^  and  /array[/],  the 
second  has  farray[2^  and  farray[3\  etc.  Curveto  has  less  overhead  than 
calling  moveto  and  lineto  directly. 

xposition(^j  ~  This  routine  returns  as  a  double  fioating  point  value,  the  x  com¬ 
ponent  of  the  current  position  after  the  CTM  transformation  has  been 
applied.  This  value  can  then  be  used  to  add  new  transformations  which 
scale  or  rotate  about  the  current  position. 

ypositionf^  —  This  routine  returns  as  a  double  floating  point  value,  the  y  com¬ 
ponent  of  the  transformed  current  position. 

screentouserfia;,  iy,  addrx,  addry)  —  The  routine  screentouser  is  used  to 
transform  screen  coordinates  (which  are  returned  by  the  input  routines) 
into  user  coordinates  which  are  used  for  the  output  routines.  The  first  two 
parameters  are  the  screen  coordinates,  integers,  and  the  second  two  the 
addresses  of  where  to  put  the  transformed  double  floating  point  values. 
Use  of  screentouser  is  essential  for  device-independent  graphics  input  in 
GPAC  programs. 

charslenfsirj  —  Charslen  returns  the  length  of  the  specified  string.  The  length  is 
measured  in  user  coordinates  and  returned  as  a  double  floating  point 
value.  The  character  sizes  of  the  font  specified  in  the  init  call  are  used. 
Control  characters  are  not  handled  corrrectly  (i.e.,  newline,  carriage 
return,  and  line  feed).  If  an  error  occurs,  -1.0  is  returned. 
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Section  VII  -  Conclusions 


First  a  few  hints  on  wise  usage  of  GPAC.  Users  should  keep  the  size  of  display  file  they 
use  as  small  as  possible.  The  routine  append  is  not  very  efficient  in  terms  of  space 
used  in  the  display  file.  Constant  polling  of  the  tablet  with  the  readposition  routine 
consumes  a  great  deal  of  system  resources.  Current  users  of  GPAC  find  the  structured 
use  of  segments  very  helpful  in  designing  and  writing  of  graphics  programs.  The  max¬ 
imum  number  of  segments  used  should  be  kept  as  small  as  possible  as  space  is  allo¬ 
cated  for  each  possible  segment  number  even  if  it  is  never  used. 

GPAC  may  be  expanded  and  improved  in  the  future.  Projected  improvements  include 
optimizing  its  internal  code  generator  and  input  modules. 

Finally  the  author  would  like  to  acknowledge  the  suggestions,  ideas  and  support  pro¬ 
vided  by  the  other  members  of  the  Dynamic  Graphics  Project:  Ron  Baecker,  Sheila 
Crossey,  Tom  Duff,  Greg  Hill,  Tom  Horsley,  Les  Mezei,  Robert  Pike,  David  Tilbrook,  Mike 
Tilson  and  Martin  Tuori.  Without  these  users  and  the  feedback  (and  bitching)  they  pro¬ 
duced,  GPAC  would  not  be  the  useful  graphics  package  it  is  today.  Finally,  to  new  users 
of  GPAC,  lots  of  luck  and  have  fun—with  computer  graphics  that's  the  name  of  the 
game. 
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Appendix  I  -  Access  to  GPAC 


GPAC  can  be  accessed  through  any  C  program  with  only  a  few  restrictions  that  will  be 
described  here.  First,  the  user  must  provide  GPAC  a  workspace  in  which  it  will  build  its 
display  file.  The  user  indicates  its  size  in  the  call  to  init  described  in  Section  V.  The 
location  of  this  workspace  must  be  the  very  first  external  data  declaration  of  the  pro¬ 
gram.  An  array  of  the  required  size,  declared  in  the  proper  position,  and  initialized  to 
zeros,  will  convince  the  C  compiler  and  loader  to  reserve  this  space.  For  example,  to 
declare  a  4K  display  file,  the  following  declaration  must  preceed  all  other  declarations 
in  the  program: 

int  df[4*1024] 

0,  0 

i; 

The  variable  name  can  be  anything  the  user  wishes.  With  this  definition  the  user  can 
call  init  with  1024,  2048,  3072  or  4096  as  the  display  file  size.  The  amount  of  data 
reserved  for  the  workspace  must  be  a  multiple  of  4K  words,  and  the  number  of  words 
used  (i.e.,  in  the  init  call)  can  be  any  multiple  of  IK  words  less  than  or  equal  to  that. 
Reasons  for  these  restrictions  are  deep  and  historical  and  will  not  be  explained  herein. 

The  second  requirement  for  GPAC  programs  is  that  they  be  compiled  to  use  I  and  D 
space  (a  hardware  feature  of  the  11/45  allowing  instruction  and  data  address  spaces  of 
user  programs  to  be  separated).  This  will  cause  the  user’s  workspace  to  be  located  at 
address  0  of  his  memory  so  GPAC  can  find  it  and  allow  it  to  be  mapped  into  a  special 
Double  Port  memory  if  the  gw  or  cv  devices  are  being  used.  This  restriction  is  not 
necesssary  for  the  nuU  and  tek  devices  but  is  currrently  insisted  upon  by  GPAC.  (A  ver¬ 
sion  of  GPAC  is  available  without  this  restriction  for  some  devices.) 

All  GPAC  routines  are  kept  in  a  series  of  libraries.  The  large  portion  of  GPAC  which  is 
device  independent  is  kept  in  the  library,  /lib/gpac/glib.  Then  for  each  device,  xxx, 
supported  by  GPAC,  there  is  a  library,  /lib/gpac/depxxx/xxxlib,  containing  the  device 
dependent  routines.  To  compile  a  C  program  with  GPAC,  the  device  independent 
library  and  one  of  the  dependent  libraries  must  be  loaded  with  the  program.  For 
example,  to  compile  a  user  program  in  a  file  demo.c  for  use  on  the  Tektronix,  the  fol¬ 
lowing  command  is  necessary: 

cc  -i  demo.c  /lib/gpac/glib  /lib/gpac/deptek/teklib 

Only  the  GPAC  routines  used  in  the  program  will  be  loaded  from  the  libraries.  All  GPAC 
internal  veLriables  and  internal  routines  begin  with  a  ’G’  (capital  g)  to  avoid  naming 
conflicts  with  a  user’s  program. 

The  gp  command  is  available  to  avoid  much  of  the  typing  indicated  above.  Its  syntax  is: 


gp  device  [-c]  [-p]  [-f]  [-0]  [-S]  [-P]  file  ... 


Device  specifies  which  of  the  devices  supported  by  GPAC,  the  user  wishes  to  use.  Thus 
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valid  devices  are  gw,  gt,  gwfake,  tek,  niiU  or  cv.  The  rest  of  the  command  line  is  argu¬ 
ments  exactly  as  in  the  cc  command.  The  user  does  not  have  to  specify  the  -i  flag,  nor 
any  of  the  libraries  when  using  gp--they  are  loaded  automatically. 

A  header  file,  which  can  be  included  in  any  user’s  program,  and  which  contains  defines 
of  all  magic  numbers  and  structures  that  are  the  user  interface  to  GPAC,  can  be  found 
in  /lib/gpac/gpac.h  or  on  the  sys  include  library  <gpac.h>.  In  particular,  it  contains 
definitions  of  all  possible  events  and  structures  used  in  the  input  functions. 
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Appendix  II  -  Support  Programs 


prev  —  The  program  prev  is  a  previewer  for  graphic  wonder  movies.  Its  user 
interface  is  a  menu  on  the  graphic  wonder  with  interactions  on  the  tablet. 
The  user  hits  the  appropriate  light  button  and  prev  asks  for  the  appropri¬ 
ate  value  to  be  typed  in  below  the  menu  in  the  scroller  region  or  executes 
the  command  if  possible.  Default  values  when  prev  is  started  are:  start¬ 
ing  frame  -  1,  frames  per  second  -  24,  frame  increment  -  1,  cycle  flag  -  on 
and  frame  counter  -  off.  Some  of  the  controls,  like  cycle  flag  and  frame 
conunter  are  on-off  flags  which  aire  inverted  by  hitting  the  appropriate 
light  button.  Others  require  a  numerical  value  which  the  user  is 
requested  to  type  in.  To  start  playback,  hit  the  button  start.  To  stop,  hit 
stop.  Continue  attempts  to  continue  from  the  last  frame  displayed  when 
stop  is  hit.  Do  not  attempt  to  change  any  of  the  parameters  while  the 
film  is  running;  hit  stop  first.  (See  man  1  prev). 

playback  --  Playback  is  a  program  to  control  film  playback  with  communication 
down  a  pipe  instead  of  on  the  tablet  as  in  prev.  It  accepts  the  following 
commands  its  standard  input, 

sf  xxxx  "  Starting  frame  is  xxxx 

ef  xxxx  —  Ending  frame  is  xxxx 

fi  xxxx  —  Frame  incriment  is  xxxx.  Every  xxxxth  frame  is  shown. 

fp  xxxx  “  Frames  per  second  is  xxxx. 

cf  X  —  The  cycle  flag  is  turned  on  if  x  is  "o”  and  off  otherwise.  When 
the  cycle  flag  is  on,  playback  will  jump  back  to  the  starting 
frame  when  it  reaches  the  ending  frame  without  stopping. 

fix  —  This  command  causes  playback  to  display  a  frame  counter  if 
X  if  "o"  and  not  to  display  it  if  x  is  "n". 

st  —  The  film  is  played  back  when  this  command  is  given. 

sp  —  The  playback  of  the  film  is  stopped. 

CO  —  Playback  is  restarted  from  where  it  was  last  stopped. 

qu  —  The  program  exits. 

Each  command  is  terminated  with  a  newline  but  othenvise  it  is  free 
format.  The  same  default  values  as  in  prev  are  in  effect  when  the  pro¬ 
gram  starts.  Playback  is  located  in  the  file  /lib/gpac/playback. 
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scroller  —  The  Graphic  Wonder  scroller  is  the  program  which  echos  in  software 
character  typed  at  the  Graphic  Wonder  keyboard.  It  also  accepts  special 
commands  from  the  keyboard  in  the  following  form:  {the  notation  MCx, 
where  x  is  a  character,  means  depressing  the  meta,  ctrl  and  x  keys  all  at 
once  “  Mx  and  x  keys  all  at  once  -  Mx  means  entering  meta  and  x  at  the 
same  time) 

MCX  --  The  scroller  gives  the  Graphic  Wonder  screen  up  to  other 
programs  but  the  keyboard  is  still  active  and  can  be  used  to 
type  "in  the  dark”  with. 

MCY  —  The  scroller  tries  to  regain  the  screen.  If  it  fails  (usually 
because  something  else  has  the  gw  open),  the  user  is  signed 
off. 

MCC  —  Clears  the  screen. 

MCS  —  Slops  edl  output  to  the  screen  until  a  MCG  or  MCP  are  typed. 
This  feature  is  very  useful  for  scanning  files  but  users  are 
cautioned  that  scrolling  large  files  eats  CPU  a  lot,  so  other 
users  may  become  annoyed  at  persistant  use. 

MCG  —  Restarts  output  to  the  screen. 

MCP  --  Causes  a  page  (defined  to  be  the  number  of  lines  the 
scroller  is  able  to  put  on  its  screen  area)  to  be  allowed  to 
scroll  onto  the  screen  but  no  more.  To  look  at  a  sequence  of 
pages  repeated  MCP’s  are  needed. 

MCV  —  MCV  is  used  to  set  the  viewport  and  scale  of  the  scroller.  To 
input  the  commands  type  MCV  followed  by  a  sequence  of  one 
or  more  of  the  following  : 

MTxxx  —  Set  the  top  limit  of  the  scrolling  region  to 
XXX  where  xxx  is  in  screen  coordinates  (0- 
1023). 

MBxxx  --  Set  the  bottom  limit  to  xxx. 

MLxxx  --  Set  the  left  margin  to  be  xxx. 

MRxxx  —  Set  the  right  margin  to  be  xxx. 

MSxxx  --  Set  the  scale  to  xxx  (numbers  0-15  are 
meaningful) 

For  example  MCVMT512  sets  the  top  of  the  scrolling  region 
to  be  at  half  screen.  Any  non_meta  character  will  ter¬ 
minate  the  sequence. 
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To  implement  these  features  the  character  with  ASCII  code  032  has 
been  given  special  meaning.  User  programs  should  not  contain  it  if  possi¬ 
ble.  To  control  the  scroller  from  a  progreim,  the  GPAC  routine  scroller  is 
available. 

Another  feature  is  the  use  of  the  ASCII  SO  (shift  out),  SI  (shift  in) 
and  ESC  characters.  The  character  following  an  ESC  or  when  the  scroller 
is  in  shifted  out  mode  will  have  the  0200  bit  turned  on  so  character  sets 
can  become  256  characters  long.  Some  of  these  are  used  for  special 
characters  like  reverse  and  half  line  feeds  and  tabs. 

character  recognizer  trainer  —  The  recognizer  trainer  is  an  interactive  program 
allowing  a  user  to  define  a  dictionary  file  to  be  used  by  the  recognize  rou¬ 
tine  of  section  III.  Basically  it  asks  the  user  to  draw  examples  of  each  of 
the  symbols  that  are  to  be  recognized  and  saves  information  on  them  in 
the  dictionary.  The  documentataion  for  the  trainer  is  currently  in 
/  sys/source/gpac/ gpacdoc/trainer. 

build  interp  —  The  build  interp  library,  in  /lib/gpac/build_interp,  is  used  by 
programs  to  create  interp  files  which  can  then  be  used  with  the  interp 
routine  of  GPAC.  Interp  files  are  just  a  means  of  storing  GPAC  calls  in  a 
file  rather  than  having  them  as  actual  code.  The  list  of  GPAC  routines 
callable  from  an  interp  file  is: 

gopen,  gclose,  append,  delete,  post,  unpost,  chars,  intens.  line. 

line  to,  move,  move  to 

Users  can  build  a  C  program  that  calls  the  desired  functions  with  normal 
GPAC  routines  including  an  init  and  finish  (Note  that  finish  must  be 
called!!).  The  pictures  created  can  be  debugged  on  one  of  the  normal 
GPAC  devices.  When  satisfied  with  the  results,  the  init  call  is  changed  so 
it  has  only  one  argument,  the  name  of  the  interp  file  to  be  generated. 

Then  the  program  is  recompiled  vrith  the  build _ interp  library.  When  the 

resulting  load  module  is  executed  the  interp  file  will  be  generated.  The 
command  gpbuild  is  available  to  perform  the  linking  of  the  user’s  pro¬ 
gram  to  the  build _ interp  library.  It’s  syntax  is: 

gpbuild  [-c]  [-p]  [-f]  [-0]  [-P]  [-S]  file  ... 

The  arguments  are  exactly  the  same  as  those  of  the  cc  command. 

plot  “  Documentation  on  plot  is  available  in  Section  VI  of  the  UNIX 
Programmer’s  Manual 

standard  format  support  —  A  detailed  description  of  the  actual  format  is  found^ 
under  gsformat  in  the  UNIX  Programmer  s  Manual  Section  V.  This  section 
merely  summoirizes  the  capabilities  of  standard  format. 
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There  are  three  classes  of  standard  format  programs:  1)  sources,  2) 
filters  and  3)  sinks.  This  is  consistent  with  the  UNIX  pipe  facilities. 

1)  st  sources 

St  sources  are  programs  which  produce  a  standard  format  output. 
In  general  they  assume  that  they  are  producing  a  display  for  a 
4096  by  4096  screen.  They  need  not  provide  capabilities  for 
transforming,  clipping,  editing,  etc.  since  these  can  be  provided  in 
common  for  any  standard  format  file. 

Examples  are: 

txtost(VI)  --  text  to  steuidard  format 
gwtQst(VI)  --  GW  snap  file  to  standard  format 
GPAC(IV)  —  graphics  package 
halfwit(VI)  —  sketching  and  sketch  editing 


2)  st  filters 

St  filters  provide  methods  of  manipulating  and  transforming  stan¬ 
dard  format  files. 

Examples  are: 

GPAC(IV)  ~  graphics  package. 

stost(VI)  —  transform,  clip,  concatinate,  expand,  etc. 
standard  format  files 

stfill(V])  —  expand  standard  format  files  with  fill  com¬ 
mands 

stofst(VI)  ~  convert  to  fioating  standard  format 
halfwit(VI)  —  sketch  editor 


3)  st  sinks 

St  sinks  take  a  stzindard  format  file  and  provide  a  visual  result.  All 
device  dependency  should  be  contained  in  them. 

Examples  are: 

stogw(VI)  —  standard  format  to  Graphic  Wonder 
stocv(VI)  “  standard  format  to  Colour  Video 
stovc(VI)  —  standard  format  to  Versatec 
printer/plotter 

stotek(VI)  —  standard  format  to  Tektronix 
stoards(VI)  —  standard  format  to  Ards 
stolp{VI)  -  standard  format  to  line  printer  and  tty 
graphics. 

stan(VI)  ~  get  information  about  a  particular  stan¬ 
dard  format  file 

stomni(VI)  --  standard  format  to  Omni  terminal 
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plot(VI)  —  standard  format  to  Calcomp 
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Appendix  III  -  A  GPAC  Tutorial 


Almost  everyone  has  been  presented  with  the  classic  first  program  in  a  new  program¬ 
ming  language: 

main() 

i 

printf("hi  there\n"); 

With  GPAC  probably  the  most  simple  program  that  can  be  written  is: 

int  df[4096]  |0j; 
main{) 

[ 


init{4096.  0.  1,  "fixed.k"); 
gopen(l); 

moveto(512.,  512.); 

Iineto(l000.,  1000.); 

gcloseO; 

post(l): 

update(); 

finish(); 

i 

Clearly  you  have  to  work  a  lot  harder  to  make  your  first  GPAC  program  go.  But  the  end 
results  are  so  much  more  rewarding.  Just  imaigine  that  line  streaking  across  the 
screen!!!  (See  figure  1). 

Lets  examine  the  above  example  a  bit  more  seriously.  It’s  not  in  the  best  of  program¬ 
ming  style  as  there  are  magic  numbers  everywhere  instead  of  symbolic  constants. 
Ignoring  that,  first  notice  that  the  graphics  primitives  take  floating  point  arguments. 
Here  constants  are  used  but  variables  or  expressions  are  just  as  acceptable  as  in: 

moveto(x-2.5*z,  y); 
or 

lineto(sqrt(x*x),  sin(3. 141592)); 

Using  float  variables  or  expressions  as  arguments  to  graphical  primatives  works  just  as 
well  as  doubles  but  using  integers  or  characters  as  arguments  to  these  routines  will 
result  in  erronous  pictures  and  at  times  program  failure.  All  parameters  to  GPAC  rou¬ 
tines  must  match  the  types  as  specified  in  this  manual. 

The  graphics  primitives  are  surrounded  by  calls  to  gopen  and  gclose.  which  open  seg¬ 
ment  number  one.  to  receive  picture  information  and  terminate  the  creation  of  seg¬ 
ment  one  respectively.  Gclose  needs  no  argument  as  GPAC  remembers  the  segment 
number  of  the  currently  open  segment.  The  call  to  post  will  make  segment  one  visible 
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when  a  page  is  plotted  by  the  following  call  to  update.  On  the  gw  device  where  the  vir¬ 
tual  screen  is  equal  to  the  real  screen,  the  segment  is  visible  immediatly  after  the  call 
to  post.  The  call  to  init  sets  up  GPAC  with  a  workspace  of  4098  words  and  with  no  input 
functions  desired.  Only  one  segment  is  needed  and  the  requested  font  is  fixed,  k.  The 
declaration  of  GPAC's  workspace  is  achieved  by  df  in  the  first  line. 

The  following  program  is  a  very  trivial  program  to  draw  a  box  and  a  triangle  on  the  out¬ 
put  page.  It  illustrates  the  use  of  multiple  segments  and  the  chairs  routine. 

# 


/• 

*  Program  to  draw  a  box  and  triangle  on  page. 

V 

#define  BOX  1 
#define  TRI  2 
#define  DF^SIZE  4096 
#define  MAX^SEGS  10 
#define  FONT  "fixed.k” 

int  workspace[DF_SIZE]  |0,0j; 

main() 

f 

/• 

*  Initialize  for  a  display  file  of  4098 

*  words  and  a  maximum  of  10  segments. 

*/ 

init(DF_SIZE.  0,  MAX_SEGS,  FONT): 

/* 

*  Open  the  segment  number  box  to  accept  graphics 

*  primitives. 

V 

gopen(BOX); 

/* 

*  Draw  a  box. 

•/ 

moveto(512.,  512.); 
line(300.,  0.); 
lme(0.,  300.); 
line(-300.,  0.); 
line(0.,  -300.); 
charsC’BOX"): 

/* 

*  Finish  with  segment  box. 

*  and  make  it  visible  by  posting  it. 

*/ 
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gcloseO: 

post(BOX); 

/* 

*  Plot  box. 

V 

update(); 

/• 

*  Make  a  triangle  at  100,  100. 

•/ 

gopen(TRI); 
moveto(l00.,  100.); 
lineto(300.,  100.); 
lineto(200.,  200.); 

Iineto(l00.,  100.); 
chars(''triangle"); 
gcloseO: 
post(TRI); 

/* 

*  Signal  GPAC  to  plot  the  current  picture. 

•/ 

update(); 

/* 

*  Remove  box  from  virtual  screen  eind  plot. 

*/ 

unpost(BOX); 

update(): 

/* 

*  Unpost  triangle  and  repost  box.  Then  plot. 

V 

unpost(TRI); 

post(BOX); 

update(); 

/• 

*  Terminate  the  program. 

.  */ 

finishO; 


The  output  produced  by  this  program  is  shown  in  figures  2.a.,  2.b.,  2.c.,  and  2.d.  Here 
chars  takes  as  argument  a  string  constant.  Other  possibilities  are  shown  by  the  follow¬ 
ing  definitions  and  calls: 

char  name[]  "boris  krulkov"; 
char  ^address  "43  wingham  dr."; 

moveto(400.,  440.); 
chars(name); 
move(0.,  -20.); 
chars(address): 
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This  next  program  demonstrates  the  transformation  features  of  GPAC.  The  window  is 
set  to  be  centred  at  the  origin  0.0,  0.0.  A  grid  is  drawn  over  the  whole  page.  Then 
viewport  is  used  to  medce  the  viewport  be  the  upper  right  quadrant  and  a  series  of 
rotated  boxes  are  drawn  at  various  scales. 

# 


/• 

•  Rotated  box  drawer. 

V 

#define  DF_SIZE  4096 
#define  MAX_SEGS  11 
^define  FONT  "fixed. k" 

#define  NBOXES  10 
^define  GRID  11 

int  df[DF_SIZE]  [0,  0\; 

double  sc  ales  [NBOXES] 

I  .1.  .2,  .4,  .8.  1.6,  1.6,  1.6,  .8.  .4,  .2]; 
double  angles[NB0XES] 

{  .3,  .6.  .9.  1.2,  1.5,  1.8,  2.1,  2.4,  2.7,  3.0?; 


main() 

f 

int  i; 

init(DF_SIZE.  0,  MAX^SEGS,  FONT); 

/• 

*  Define  a  window  onto  the  picture  space  centred 

*  at  0.,  0.  and  having  sides  length  1024.  in  both 

*  directions. 

*/ 

window(0.0,  0.0,  512.,  512.); 

/* 

*  Draw  a  2  by  2  grid  over  the  screen. 

V 

gopen(GRID); 
moveto(-512.,  -512.); 
box(l024.); 
moveto(-512.,  0.0); 

Une(l024.,  0.0); 
moveto(0.0,  -512.); 
line(0.0,  1024.0); 
gcloseO; 
post(GRID); 

/* 
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•  Set  viewport  to  be  the  upper  right  quadrant. 

V 

viewport(.75,  .75,  .25,  .25); 

for(i  =  1;  i  <=  NBOXES;  i+  +  ) 

[ 

gopen(i); 

pushmat(); 

scale(scales[i-l],  scales[i-l]);  /•  Zero  Origining  •/ 

rotate(ajigles[i-l]); 

moveto(200.,  0.); 

box(40.); 

post(i);  /*  Note  post  does  a  gclose()  for  you  '•'/ 
popmat(); 

i 

update(): 

finishO; 


box(dside) 
double  dside; 

I 


line(dside,  0.0): 
line (0.0,  dside); 
line(-dside,  0.0); 
line(0.0,  -dside); 

The  output  produced  is  shown  in  figure  3.  The  pushmat  aind  popmat  routines  aire  used 
to  save  and  restore  the  transformation  matrix  for  each  separate  scale  and  rotation. 
Otherwise  the  transformations  would  be  cumulative. 

The  following  is  another  trivial  program  to  draw  intensity  patterns  and  also  make  a  film 
of  them. 

# 


/* 

*  Program  to  generate  intensity  grids 

•  and  make  a  film  of  them  as  well. 

V 

int  df[4*1024]  /*  Display  file  workspace  •/ 

I 

0.  0 

int  nlines;  /*  Number  of  lines  in  current  grid  •/ 
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double  dx;  /*  Spacing  between  grid  lines  */ 
double  dy:  /*  Vertical  height  of  a  grid  line  */ 


main() 

register  int  i; 
register  int  y. 


/* 

* 

* 

« 

* 


Initialize  a  display  file  of  4K 
words  with  no  input  functions  desired,  a 
maximum  of  1  segment  eind  using  the  font 
"fixed.k". 


V 

init(4»1024.  0,  1,  "fixed.k"); 

/* 

*  The  resulting  film  will  be  stored  in  the 

*  file  "intfilm”,  in  the  current  directory. 

V 

beginfilm(''intfilm''); 

for{;:) 

printf(''number  of  lines  ? 

nlines  =  rin():  /*  Read  an  integer  ♦/ 

if(nlines  ==  0)  /*  Terminate  on  0 

I 

printf("nframes  %d\n’',  endfilm()); 

finish(); 

exit(); 

i 

nlines  =  (nlines>>4)<<4: 

printf("give  you  %d  lines\n",  nlines): 

gopen(l); 

dx  =  975. /nlines; 

dy  =  975.; 

moveto(25.,  25.); 

for(i  =  0;  i  <  16;  i++) 

I 

intens(i); 

for(j  =  0;  j  <  nlines>>4;  j++) 

I 

line(0.0,  dy); 
move(dx,  -dy); 

1 

i 

post(l); 

/•  Hold  each  image  for  100  frames  •/ 

frame(lOO); 

include(l); 


V 
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The  final  example  program  demonstrates  the  input  functions  of  GPAC,  Three  light  but¬ 
tons  are  maintained  by  the  program.  The  draw  button  allows  the  user  to  use  inking  to 
input  a  picture.  The  display  button  causes  the  last  drawn  picture  to  be  displayed  in 
one  of  three  small  display  viewports  on  the  right  of  the  screen.  When  all  viewports  are 
full,  they  are  replaced  cyclically.  The  exit  button  terminates  the  program.  Note  that 
the  viewport  and  screentouser  routines  are  used  to  scale  the  input  points.  In  the  rou¬ 
tine  readpic,  the  inked  points  returned  by  getevent  are  removed  and  saved  in  a 
separate  set  of  structures  so  on  subsequent  calls  the  data  will  not  be  lost.  The  routines 
alloc  and  free  (described  in  section  3  of  the  UNIX  Programmers  Manual)  are  very  use¬ 
ful  in  providing  dynamic  memory  allocation  of  arrays  and  structures.  The  finer  work¬ 
ings  of  this  program  are  left  as  a  exercise.  Figure  4  is  a  sample  screen  image  from  this 
program. 

# 

^define  cycle  for(:;) 

/* 

♦  GPAC  Declarations 

V 

#define  DF_SIZE  4096 
#define  INK_SIZE  1024 
#define  NSEGS  10 
#define  FONT  "fixed.k” 

#define  TRKSEG  10 
#define  INKSEG  9 
#define  WAITSEG  8 
#define  FOOLSEG  7 
#define  MENUSEG  6 
#define  DRAWREGION  6 

#define  DRAW  0 
#define  DISPLAY  1 
#define  EXIT  2 

int  df[DF_SIZE]  |0.  Oj; 

#define  INKING  3 
#define  Z_AX1S_D0WN  6 

/* 

♦  Structures  for  inking 

V 
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struct  xypair 

f 

int  x; 
iut  y: 

I  xypair; 

struct  curve 

! 

int  npts; 

struct  xypair  pts[l]: 

i: 

struct  curves 

int  ncurves; 

struct  curve  *c_ptr[l]: 

!; 

/• 

*  A  few  global  variables 

•/ 

int  npts,  ncurves; 
int  *len; 

struct  xypair  *pt;  xypair  *pt; 
int  segno; 
struct  event 

[ 

int  type; 
int  xpos; 
int  ypos; 
int  status; 

struct  curves  *ink;_ptr; 

!; 

/• 

*  Mainline.  Initialize  display  and  segments. 

*  Then  forever,  input  the  user’s  command, 

*  detect  which  light  button  was  hit,  and 

*  execute  the  appropriate  routine. 

*/ 

main() 

I 

register  struct  event  •ep; 
double  xc,  yc; 

initialize(); 

cycle 
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i 


menu(); 

track(TRKSEG); 

ep  =  getevent{); 

switch(hitdetect(ep->xpos,  ep->ypos)) 

! 

case  DRAW: 

unmenuO; 
readpic(): 
break; 
case  DISPLAY: 

if(++segno  >  3) 
segno  =  1; 
gopen(segno); 
xc  =  .875; 

yc  =  .25*segno-.  125; 
viewport(xc,  yc,  .125,  .125); 
drawpic(); 
post(segno); 
break; 
case  EXIT: 

finishO; 

exit(); 

default: 

fool(); 

i 

i  ' 


/• 

*  Initialize  device  and  segments. 


initializeO 

Lnit(DF_SIZE,  INK_SIZE,  NSEGS,  FONT); 

g  open(TRKSEG) ; 

moveto(512.,  512.); 

line(5.,  0.); 

move(-5.,  5.); 

line(0..  -10.); 

move(-5.,  5.); 

line(5.,  0.); 

gcloseO; 

gopen(INKSEG); 

moveto(512.,  512.); 

line(0.,  1.); 

move(-5.,  4.); 

line(0.,  -10.); 


-42- 


GPAC  Tutorial 


GPAC  Users*  Manual 


Une(lO.,  0.): 
line(0.,  10.); 

Iine(-10.,  0.); 
gcloseO: 

ciirsor(l,  INKSEG): 
gopen(WAITSEG); 
moveto(512,,  512.); 
charsCWAlT"); 
gcloseO; 

cursor(0,  WAITSEG); 
gopen{F00LSEG); 
moveto(512.,  512.); 
chars(''F00L"); 

crnlospO* 

gopen(MENUSEG); 
moveto(l00.,  900.); 
charsC'DRAW"); 
moveto(300.,  900.); 

charsODISPLAY’'); 

moveto(500.,  900.); 

charsC'EXIT''): 

gcloseO; 

gopen{DRAWREGI0N); 
viewport(.375.  .375,  .375,  .375); 
moveto(0.0,  0.0); 
line(l023.,  0.0); 
line(0.0,  1023.); 

Ime0l023..  0.0); 
line(0.0,  -1023); 
moveto(450.,  1000.); 
chars("Dra’wing  Region"); 
post(DRAWREGION); 
activate(Z_AXIS_D0WN.  0); 

1 

fool() 

! 

track(FOOLSEG); 

sleep(2); 

track(TRKSEG); 

1 

menuO 

[ 

post(MENUSEG); 

I 
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unmenuO 

I 

unpost(MENUSEG); 

1 


/* 

*  Very  simple  light  button  detection. 

V 

hitdetect(x,  y) 
int  X,  y; 

[ 

if(y  <  850  B  y  >  950  II  X  >  600) 
return(-l); 
return((x-100)/200); 

I 

/* 

*  Copy  data  from  ink  structures  of  GPAC 

*  into  the  array  of  xypair  structures  pt. 

*  Array  len  retains  the  length  of  each  curve. 

*  Apologies  are  made  for  the  entwined  code  and 

*  the  use  of  pointers. 

V 

readpicO 

! 

register  struct  event  *eventp; 
register  struct  curves  *evec; 
register  struct  curve  *cur; 
double  ax,  ay; 
struct  xypair  •ptp; 
int  k,  I,  j,  i; 

'struct  xypair  *ptr; 

activate(INKING.  0); 
viewport(.375.  .375,  .375,  .375); 
while((eventp  =  getevent())->type  ?=  INKING) 
fool(); 

tr  ac  k(TRKSEG) ; 

evec  =  eventp->ink_ptr; 
cur  =  evec->c_ptr[0]; 
npts  =  0; 

for(j  =  1;  j  <=  evec->ncurves;  j++) 

i 

npts  =+  cur->npts; 
cur  =  evec->c_ptr[j]; 
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i 

cur  =  evec->c_ptr[0]; 
ncurves  =  evec->ncurves; 
if(len) 

free(len); 

len  =  alloc  (2*ncurves); 
for(j  =  0;  j  <  ncurves:  j++) 

len[j]  =  evec->c_ptr(j]->npts; 

if(pt) 

free(pt); 

pt  =  alloc(npts*sizeof  xypair); 
ptp  =  pt; 

for(j  =  1;  j<=evec->ncurves;  j++) 

s 

for(l  =  0;  1  <  cur“>npts;  1++) 
ptr  =  &:cur->pt3[l]; 

screentouser(ptr->x,  ptr->y,  &ax,  &:ay); 
ptp->x  =  ax;  (ptp++)->y  =  ay; 

1 

cur  =  evec->c__ptr[j]; 

i 

deactivate(INKING); 


/• 

*  Draw  the  data  in  the  pt  and  len  structures. 


drawpicO 

[ 

register  i,  j,  k; 
char  cbuf[40]; 

clearink(): 
k  =  0; 

for(i=0:i<  ncurves;  i++) 

moveto(pt[k].x+0.0,  pt[k].y+0.0); 
k++; 

for(j=  l;j<len[i];  j++) 

lineto(pt[k].x4-0.,  pt[k].y+0.0); 
k+  +  ; 

moveto(50.,  25.); 

chars(stringf(cbuf,  "npts  -  %d'',  npts)); 


-45- 


GPAC  Users’  Manual 


GPAC  Tutorial 


moveto(0.0,  0.0); 
line(l023.,  0.); 
line(0.,  1023.); 
line(-1023.,  0.); 
line(0..  -1023.); 

I 
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Appendix  IV  -  Error  Messages 


This  appendix  presents  for  each  GPAC  routine  a  list  of  error  messages  that  may  be  pro¬ 
duced.  The  format  of  a  GPAC  error  message  is: 

GPAC  ERROR  -  routme__name  :  description  of  error 
The  following  lists  of  errors  will  only  give  the  description  portion  of  the  message.  Por¬ 
tions  of  the  message  indicated  by _  are  dependant  on  the  user  call  that  produced 

the  error. 


move,  moveto,  line,  lineto,  fillbegin,  fillend,  and  chars 

DISPLAY  FILE  FULL 
Segment  not  open 


gopen 

Invalid  segment  number 
Multiple  segments  open 

append 

Invalid  segment  number 
Multiple  segments  open 
Non-existent  segment 

delete 


Invalid  segment  number 
Non-existent  segment 
post,  unpost 

Invalid  segment  number 
Non-existent  segment 

scale 


Invalid  args _ 

viewport 

Invalid  viewport _ 

pushmat,  pushstate 

Can  not  allocate  core 
popmat,  popstate 

Stack  is  empty 


activate 


Invalid  event 

Cannot  activate _ on  this  device 


deactivate 

Invalid  event 

Cannot  deactivate _ on  this  device 

getevent,  ink 

Cannot  allocate  core 
Cannot  get  an  event 

inkparms 

Invalid  arguments _ 

readposition 

Read  error  on  tablet 


cursor 

Invalid  segment  number 
Non-existent  segment 
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track 

Invedid  segment  number 
Non-existent  segment 

beginfilm 

Failed  to  open _ 

Cannot  allocate  core 
endfilm,  include 

Write  error 

frame 

Negative  duration 
Invalid  segment  number 
Non-existent  segment 

init 

Bad  display  file 
Cannot  allocate  core 
Cannot  open  font  file 
Font  too  big 
Cannot  open  tablet 

interp 

Cannot  open  interp  file 
Read  error 

scroller 

Invalid  command _ 


snap 

Cannot  open  snap  file 

Cannot  fork 

Cannot  open  snap  pipe 
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Appendix  V  -  Hardware  Dependencies 


GPAC  is  capable  of  interfacing  directly  with  four  graphics  terminals:  a  Graphic  Wonder, 
a  Tektronix  4013,  a  Colour  Video  System,  and  a  DEC  Gt40.  Indirect  interfaces  Eire  avail¬ 
able  to  a  Versatec  Printer  Plotter  and  a  Calcomp  Microfilm  plotter. 

The  Graphic  Wonder  is  a  high  quality  refresh  display  capable  of  drawing  100,000  short 
vectors  in  a  30th  of  a  second.  All  characters  are  drawn  in  software  so  user  defined 
fonts  may  be  used.  The  Graphic  Wonder  has  16  different  intensity  levels.  Input  facilities 
for  the  gw  are  provided  by  a  Summagraphics  Digitizing  Tablet  capable  of  sampling 
points  on  its  digitizing  surface  at  up  to  200  points  per  second.  The  tablet  consists  of  a 
pen  or  cursor,  a  button  box  and  a  Dynamic  Graphics  Project  foot  pedal. 

The  Tektronix  4013  is  a  direct  view  storage  tube  display  capable  of  drawing  a  very  large 
number  of  lines  but  at  a  slow  rate.  The  terminal  is  equipped  with  cross  hairs,  con¬ 
trolled  with  two  thumbwheels,  which  are  used  for  input. 

The  Colour  Video  System  is  a  raster  scan  display  capable  of  displaying  256  by  256  pixel 
pictures  composed  of  up  to  256  different  colours.  These  256  colours  can  in  turn  be 
chosen  from  among  the  billions  available  in  the  colour  map.  Input  facilities  will  include 
an  interface  to  the  tablet  described  above. 

The  DEC  Gt40  is  a  medium  quality  refresh  display  capable  of  drawing  about  500  vectors 
in  a  60th  of  a  second.  All  characters  are  drawn  in  a  heirdware  defined  font.  The  Gt40 
can  display  vectors  at  8  different  intensity  levels.  Currently  no  input  facilities  have 
been  implemented  but  possibilities  exist  for  a  tablet  interface  similar  to  that  of  the 
Graphic  Wonder  and  a  light  pen  interface. 

To  interface  to  the  other  devices,  GPAC  edso  allows  the  use  of  the  null  device.  This  dev¬ 
ice  will  output,  onto  the  standard  output,  a  standard  format  representation  of  the 
created  picture  whenever  update  (I)  is  called.  Thus  the  users  program  can  be  piped  to 
the  Versatec  Scan  Converter  or  to  the  Microfilm  formatter  (Appendix  II)  for  hardcopy. 
The  null  device  is  also  useful  for  debugging  programs  when  no  graphics  terminal  is 
available. 

GPAC  also  has  a  device  called  gwfake.  This  device  functions  exactly  like  to  gw  device 
except  no  graphics  memory  is  occupied  and  no  image  is  visible.  The  device  is  mainly 
useful  for  computing  long  movie  sequences  in  gw  format  and  for  debugging.  In  the 
hardware  dependencies  listed  below  the  gwfake  device  is  exactly  the  same  as  the  gw 
device. 

The  following  sections  describe  some  of  GPAC’s  hardware  dependencies  on  each  device. 
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Characters 


Character  sizes  and  fonts  are  device  dependent.  The  following  table  describes  for  each 
device  the  most  important  information.  The  font  name  is  the  string  used  as  argument 
to  the  init  routine  of  section  IV.  The  font  size  is  amount  of  space  in  the  display  file  the 
font  will  occupy. 


1  Font 

1  Font 

1  Character  Sizes 

Device 

1  Name 

1 

1  Size 

1 

1  Width 

1  

Height 

gw 

1 

1  bodoni.k 

1 

1 

1  1.7K 

1 

1 

1  13 

1 

10 

1 

1  fixed. k 

1 

1 

1  I.IK 

1 

1  10 

1 

10 

1 

1  npal.k 

1 

1 

1  .8K 

1 

1 

1  6 

1 

6 

1  nulLk 

1 

1  .25K 

1 

1  0 

1 

0 

1 

1  roman.k 

1 

1 

1  2.5K 

1 

1  18 

1 

18 

1 

1  lombardic.k 

1 

1 

1  3.2K 

1 

1  18 

1 

18 

1 

1  script. k 

1 

1  2.6K 

1 

1  18 

1 

18 

1 

1  english.k 

1 

1  3.7K 

1 

1  18 

1 

18 

1 

1  astro. k 

1  2.  OK 

1 

1  18 

1 

18 

1 

1  cyrillic.k 

1 

1 

1  2.8K 

1 

1  18 

1 

18 

I 

1  greek.k 

1 

1  2.6K 

1 

1  18 

1 

18 

. 

1 

1  triplex,  k 

1 

1  3.5K 

1 

1  18 

1 

18 

1 

1  italic. k 

1 

1  2.6K 

1 

1  18 

1 

18 

1 

1  german. k 

1 

J 

1 

1  3.7K 

1 

J 

1  18 

1 

1 

18 

tek 

1 

1  Only  hardware  font 

1 

1  .  1 

1 

1  14 

1 

1 

14 

gt 

1 

1  Only  hardware  font 

1 

J_1 

1 

1  10 

1 

1 

10 

1  1  1 
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null 

1 

1 

1 

same  as  gw 

I  same 

1 

1 

1  4  times  sizes  of  gw 

1 

1 

cv 

1 

1 

same  as  gw 

1  same 

1 

1  .65  times  sizes  of  gw 

The  character  sizes  are  expressed  in  screen  coordinates,  which  are  defined  below. 
Vie^upoTts 

When  a  user  defines  a  viewport,  he  defines  which  portion  of  the  screen  onto  which  his 
graphical  information  is  to  be  mapped.  If  the  user  wishes  to  use  the  device  indepen¬ 
dent  viewport  routine,  viewport,  the  following  are  the  viewport  coordinate  space  limits 
for  the  different  devices. 


Device 

1  Viewport  Space  Limits 

1  X  Y 

1 . . . . . 

1  Initial  Viewport 

1  X  Y 

^ 

gw 

1 

1  0.0->1.0 

1 

0.0->1.0 

1 

1  0.0->1.0 

1 

0.0->1.0 

gt 

1 

1  0.0->1.0 

1 

O.O-M.O 

1 

1  O.O-M.O 

1 

0.0->1.0 

tek 

1 

1  -.1516->  1.1516 

1 

0.0->1.0 

1 

1  0.0->1.0 

1 

0.0->1.0 

null 

1 

1  0.0->1.0 

1 

0.0->1.0 

1 

1  0.0->1.0 

1 

0.0->1.0 

cv 

1 

1  0.0->1.0 

0.0->1.0 

1 

1  0.0->1.0 

0.0->1.0 

Each  device  has  its  own  screen  coordinate  space,  all  varying  in  size.  The  following  table 
gives  the  ranges  for  the  screen  coordinates  and  the  initial  viewport  set  up  by  init. 


1  Screen  Coordinates 

1  Initial  Viewport 

Device 

1  X 

1 

Y 

1  X 

1-  .  

Y 

gw 

1 

1  0-1023 

1 

0-1023 

1 

1  0-1023 

1 

0-1023 

gt 

1 

1  0-1023 

1 

0-1023 

1 

1  0-1023 

1 

0-1023 

tek 

1 

1  0-1023 

1 

0-779 

1 

1  122-901 

1 

0-779 

null 

1 

1  0-4095 

0-4095 

1 

1  0-4095 

1 

0-4095 

cv 

1 

1  0-255 

0-255 

1 

1  0-255 

0-255 
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Input  routines  return  coordinates  in  this  space  and  the  user  can  use  screentouser  to 
transform  them  back  to  his  coordinate  space  if  he  desires. 


Nop  Routines 


For  each  device  there  are  some  GPAC  routines  the  hardware  cannot  do  or  are  too 
expensive  to  do  in  software.  To  preserve  device  independence,  these  routines  are 
included  in  the  libraries  but  perform  no  functions.  Following  is  a  list  of  nop  routines 
for  each  device  supported. 

gw  —  depth,  fillend,  fillbegin,  background,  rgb,  Iwidth,  update 

gt  --  depth,  fillend,  fillbegin,  background,  rgb,  Iwidth,  update  activate, 
deactivate,  ink,  inkparms,  clearink,  invisink,  visink,  track, 
un track,  getevent,  recogni2e,  scroller 

tek  ~  depth,  fillbegin,  fillend,  background,  rgb,  Iwidth.  inkparms, 
invisink,  visink,  scroller 

null  —  activate,  deactivate,  ink,  inkparms,  clearink,  invisink,  visink, 
track,  untrack,  getevent,  recognize,  scroller 

cv  —  activate,  deactivate,  ink,  inkparms,  clearink,  invisink,  visink,  track, 
un  track,  getevent,  recognize,  scroller,  chars 
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Appendix  VI  -  Special  Secret  Routines 


The  following  routines  are  very  device  dependent  and  contrary  to  the  philosophy 
of  GPAC,  but  were  easy  to  implement  and  very  useful  to  some  users. 

repositionfse5rmen^__7nxmber,  x,  y)  --  The  segment  indicated  is  moved  on 
the  screen  to  the  position  (x,  y)  in  the  user  coordinate  system. 
Thus  the  point  is  transformed  by  the  current  transformation 
matrix  into  window  coordinate  space  and  then  transformed  into 
screen  coordinates  in  the  viewport.  The  coordinates  are  double 
floating  point  values.  No  clipping  of  the  segment  is  done  when  it  is 
repositioned.  This  may  result  in  the  segment  wrapping  around  the 
screen. 

displacefsep77ienf_n7xm6er,  dx,  dy)  -*  In  the  same  manner  as  reposition, 
the  indicated  segment  is  moved  by  dx  in  the  x  and  dy  in  the  y 
directions.  The  movement  is  relative  to  current  position  of  the 
segment  in  user  coordinate  space.  Once  again,  no  new  clipping  of 
the  segment  is  done. 

wheTeis{segTnent_7iLLmbeT,  ax,  ay)  —  For  use  with  reposition  and  dis¬ 
place,  whereis  returns  the  current  position  in  user  coordinates  of 
the  indicated  segment.  Ax  and  ay  are  addresses  of  doubles  where 
the  x-y  position  is  to  be  returned. 

Teaeiintensfsegment^nuTnber,  intn)  —  This  routine  causes  the  initial 
intensity  of  the  indicated  segment  to  be  set  to  intTL  If  the  inten¬ 
sity  is  changed  pairt  way  through  the  segment,  only  the  first  por¬ 
tion  will  have  its  intensity  changed.  Valid  values  of  intn  are  in  the 
range  0-15.  When  creating  a  segment,  a  call  to  intens  before  any 
actual  line  drawing  calls  (i.e.,  before  a  line(to)  or  chars)  will  set  its 
initial  intensity. 

reaetcolourf segment  ^number,  coir)  —  This  routine  causes  the  initial 
colour  of  the  indicated  segment  to  be  set  to  coir.  If  the  colour  is 
changed  part  way  through  the  segment,  only  the  first  portion  will 
have  its  colour  changed.  Valid  values  of  colour  are  in  the  range  1- 
255.  When  creating  a  segment,  a  call  to  colour  before  any  actual 
line  drawing  calls  (i.e.,  before  a  Ime(to)  or  chars)  will  set  its  initial 
colour. 

resetlwidth^^sepmenf _ number,  lu/id)  —  This  routine  causes  the  initial  line 

width  of  the  indicated  segment  to  be  set  to  Iwid.  If  the  line  width 
is  changed  part  way  through  the  segment,  only  the  first  portion  will 
have  its  line  width  changed.  Valid  values  of  line  width  are  in  the 
range  0-15.  When  creating  a  segment,  a  call  to  Iwidth  before  any 
actual  line  drawing  calls  (i.e.,  before  a  line(to)  or  chars)  will  set  its 
initial  line  width. 
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scharsf'sca^e,  string)  —  Scbara  causes  a  character  string  to  be  drawn, 
starting  at  the  current  beam  position,  at  the  indicated  scale.  Pos¬ 
sible  scales  are  in  the  range  0-15,  with  15  the  largest.  The  clipping 
calculations  on  scaled  characters  are  wrong  at  times.  Note  that 
subsequent  calls  to  chars  will  not  cause  their  characters  to  be 
scaled. 

tabclear{9  --  When  tabclear  is  called,  the  user  program  is  suspended  until 
the  tablet  becomes  clear,  that  is,  when  no  buttons  are  pushed  and 
the  stylus  is  in  range. 

tabsizefresoZiiiionJ  —  The  tablet  surface  can  be  mapped  onto  the  gw 
screen  in  two  ways.  The  default  is  full  resolution,  resolution==l, 
where  the  whole  surface  is  mapped  onto  the  screen.  The  other  is 
quarter  resolution,  resolution=  =  0,  where  the  bottom  left  hand 
quarter  of  the  tablet  is  mapped  onto  the  full  gw  screen.  Actually 
every  quarter  of  the  screen  is  mapped  onto  the  screen  in  this 
mode  so  wrapping  may  cause  some  discomfort  but  also  some  con¬ 
venience. 

tabrelfj  —  This  routine  releases  the  tablet  for  use  by  another  program. 
No  GPAC  input  routines  may  be  called  before  the  tablet  is  aquired 
again.  To  regain  the  tablet,  use  the  routine  tabget  below. 

tabgetfj  -  If  the  tablet  has  been  released  with  tabrel,  this  routine  will  get 
it  back  again  if  it  is  avedlable.  It  will  return  an  error  if  the  tablet  is 
currently  in  use  by  someone  else. 

scto\\gt( command,  arg)  —  Scroller  is  used  to  communicate  with  the 
"  scroller  process  echoing  text  typed  at  the  gw  terminal.  In  organiz¬ 
ing  a  graphics  program  it  is  usually  very  desirable  to  have  text 
input  by  the  user  or  output  by  the  program  appear  at  a  specific 
location  on  the  screen.  When  running  with  any  other  device,  the 
call  is  ignored.  The  following  values  of  command  cause  the  indi¬ 
cated  results; 

0  -  The  scroller  gives  up  its  graphics  core  (making  more  avail¬ 
able  for  the  user)  and  all  echoing  stops. 

1  -  The  scroller  comes  back  to  life,  acquires  some  core  and 

starts  echoing  onto  the  screen. 

2  -  All  characters  echoed  on  the  screen  are  removed  and 

scrolling  starts  from  the  top  of  the  scroller's  viewport. 

3  -  The  scroller’s  viewport  is  changed  so  that  it's  top,  bottom, 

left  and  right  edges  are  arg[0],  arg[l],  arg[2]  and  arg[3] 
respectively.  The  coordinates  are  in  screen  units  (0- 
1023).  A  screen  clear  is  performed  as  well. 

4  -  The  scale  at  which  characters  are  echoed  by  the  scroller 

is  changed  to  arg[0].  Scales  can  range  from  0  (smal¬ 
lest)  to  15  (largest).  The  differences  between  scales  is 
logarithmic  with  8  being  the  normal  scale  factor  of  the 
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characters.  A  screen  clear  is  also  done  when  the  com¬ 
mand  is  given. 

If  the  scroller  is  to  be  turned  off,  the  scroller  call  should  be  made 
before  the  init  of  the  device.  The  number  of  lines  in  the  viewport 
and  the  number  of  characters  per  line,  depend  on  the  scale,  the 
viewport  size,  and  the  normal  character  size,  and  must  be  deter¬ 
mined  experimentally. 

nullflushf'mode^  —  The  routine  nullflush  is  implemented  for  the  null  dev¬ 
ice.  When  called  with  argument  1,  all  subsequent  segments  are  not 
stored  in  GPAC’s  workspace  awaiting  a  call  to  update  to  write  them 
out,  but  are  immediatly  written  on  the  standard  output.  Calling 
nullflush  with  0  as  an  argumnet  sets  GPAC  back  into  storing  mode. 
This  routine  allows  huge  pictures  to  be  created  as  display  file  space 
is  not  neeeded  for  them,  but  they  can  not  be  repeated  in  subse¬ 
quent  frames  as  they  are  not  stored.  The  update  routine  is  still 
operational  but  only  results  in  blank  pictures. 

nullupdate(7  “  This  routine  is  used  in  conjunction  with  nullflush.  When 
called  nullupdate  will  output  a  standard  format  update  (i.e.,  frame 
advance)  command.  This  allows  multiple  frames  to  be  generated 
while  in  flushing  mode  on  the  null  device. 

upwhere(7ii6_descj  --  Upwhere  tells  the  null  device  where  to  go.  The  rou¬ 
tine  upwhere  can  be  called  before  init  to  specify  a  file  other  than 
the  standard  output  into  which  the  null  device  outputs  its  standard 
format.  The  argument,  file_^desc,  is  a  file  descripter  of  an  open 
and  write  able  file. 

partdraw^'J  —  When  very  large  pictures  are  to  be  created  with  the  nuU  dev¬ 
ice,  users  generally  run  out  of  core  in  the  display  file  before  they 
are  ready  to  post  it  and  call  update.  The  routine  partdraw  can  be 
used  to  update  pictures  in  parts.  The  user  creates  a  part  of  the 
picture  that  will  fit  in  the  display  file  in  a  series  of  segments  and 
then  calls  partdraw  which  wiU  flush  that  part  of  the  picture  out  on 
the  standard  output  but  not  append  a  Standard  Format  end-of- 
frame  command.  The  next  part  can  then  be  created  and  partdraw 
called  again.  This  can  be  repeated  until  the  complete  picture  has 
been  drawn.  Then  update  should  be  called  to  add  an  end-of-frame. 
Between  each  call  to  partdraw  the  segments  containing  the  image 
of  the  last  part  should  either  be  deleted  or  unposted  to  prevent 
them  from  being  included  twice  in  the  overall  picture. 
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BIBLIOGRAPHY  OF  CSR G  TFCHNICAL  PEPORTS+ 


*  CSRG-1  EMPIRICAL  COMPARISON  OF  LF(k)  AND  PRECEDENCE  PARSERS 

J.J.  Horning  and  W.F.  Lalonde,  September  1970 
[ACM  SIGPLA.N  Notices,  November  1  970] 

CSPG-2  AN  EFFICIENT  LALP.  PARSER  GENERATOR 

W.P.  Lalonde,  February  19^1  [M.A.Sc.  Thesis,  EE  1971] 

*  CSRG-3  A  PROCESSOR  GENERATOR  SYSTEM 

J.D.  Gorrie,  February  1971  [M.A.Sc,  Thesis,  EE  1971] 

*  CSFG-4  DYLAN  USER’S  MANUAL 

P.  E.  Bonzon,  March  1971 


CSFG-5  DIAL  -  A  PROGRAMMING  SYSTEM  FOR  INTERACTIVE  ALGEBRAIC 
MANIPULATION 

Alan  C.M,  Brown  and  J.J.  Horning,  March  1971 

CSPG-6  ON  DEADLOCK  IN  COMPUTER  SYSTEMS 
Richard  C.  Holt,  A.pril  1971 
[Ph.D.  Thesis,  Dept,  of  Computer  Science, 

Cornell  University,  1971  ] 

CSRG-7  THE  STAR-RING  SYSTEM  OF  LOOSELY  COUPLED  DIGITAL  DEVICES 
John  Neill  Thomas  Potvin,  A.ugust  1971 
[M.A.Sc.  Thesis,  EE  1971] 


♦  CSRG-8  FILE  ORGANIZATION  AND  STFUCTURE 
G.M.  Stacey,  August  1971 


CSPG-9  DESIGN  STUDY  FOR  A  TWO-DIMENSIONAL  COMPUTER-ASSISTED 
ANIMATION  SYSTEM 

Kenneth  B.  Evans,  January  1972  [M.Sc.  Thesis,  DCS,  1972] 

*  CSRG-10  HOW  A  PROGRAMMING  LANGUAGE  IS  USED 

William  Gregg  A.lexander,  February  1972 

[M.Sc.  Thesis,  DCS  1971;  Computer,  v.8,  n, 11,  November  1975] 


CSEG-11  PROJECT  SUE  STATUS  REPORT 

J.W,  A.twood  (ed,),  April  1972 

♦  CSFG-12  THPFF  DIMENSIONAL  DATA.  DISPLAY  WITH  HIDDEN  LINE  REMOVAL 

Rupert  Bramall,  April  1972  [M.Sc,  Thesis,  DCS,  1971] 

*  CSRG-13  A  SYNTAX  DIRECTED  ERROR.  RECOVERY  METHOD 

Lewis  R,  James,  May  1972  [M.Sc.  Thesis,  DCS,  1972] 


Abbreviations: 

DCS  -  Department  of  Computer  Science,  University  of  TDronto 
EE  -  Department  of  Electrical  Engineering,  University  of 
Toronto 

*  -  Out  of  print 


CSRG-14  THF  USE  OF  SERVICE  TIME  DISTRIBUTIONS  IN  SCHEDULING 
Kenneth  C,  Sevcik,  May  1972 

[Ph.D,  Thesis,  Committee  on  Information  Sciences, 
University  of  Chicago,  1971;  J?ICM,  January  1974] 

CSRG-15  PROCESS  STRUCTURING 

J. J.  Horning  and  B,  Randell,  June  1972 
[ACM  Computing  Surveys,  March  1973  ] 

CSRG-16  OPTIMAL  PROCESSOR  SCHEDULING  WHEN  SERVICE  TIMES  ARE 
HYPEREXPONENTIALLY  DISTRIBUTED  AND  PREEMTION  OVERHEAD 
IS  NOT  NEGLIGIBLE 
Kenneth  C.  Sevcik,  June  1972 

[Proceedings  of  the  Symposium  on  Computer-Communication, 
Networks  and  Teletraffic,  Polytechnic  Institute  of 
Brooklyn,  1972] 

*  CSRG-17  PROGRAMMING  LANGUAGE  TRANSLATION  TECHNIQUES 

W.M.  McKeeman,  July  1972 

CSRG-18  A  COMPARATIVE  ANALYSIS  OF  SEVERAL  DISK  SCHEDULING 
ALGORITHMS 

C.J.M.  Turnbull,  September  1972 

CSPG-19  PROJECT  SUE  AS  A  LEARNING  EXPERIENCE 

K. C,  Sevcik  e+  al,  September  1972 

[Proceedings  A.FIPS  Fall  Joint  Computer  Conference, 

V.  41,  December  1972  ] 

*  CSRG-20  A  STUDY  OF  LANGUAGE  DIRECTED  COMPUTER  DESIGN 

David  B.  Wortman,  December  1972 

[Ph.D.  Thesis,  Computer  Science  Department, 

Stanford  University,  1972] 

CSRG-21  AN  APL  TERMINAL  APPROACH  TO  COMPUTER  MAPPING 

R.  Kvaternik,  December  1972  [M.Sc.  Thesis,  DCS,  1972] 

*  CSRG-22  AN  IMPLEMENTATION  LANGUAGE  FOR  MINICOMPUTERS 

G.  G.  Kalmar,  January  1973  [M.Sc.  Thesis,  DCS,  1972  ] 

CSRG-23  COMPILER  STRUCTURE 

W. M.  McKeeman,  January  1973 

[Proceedings  of  the  USA- Japan  Computer  Conference,  1972] 

*  CSRG-24  AN  ANNOTATED  BIBLIOGRAPHY  ON  COMPUTER  PROGRAM 

ENGINEERING 

J.D.  Gannon  (ed.  )  ,  March  1973 


CSRG-25  THE  INVESTIGATION  OF  SERVICE  TIME  DISTRIBUTIONS 

Eleanor  A.  Lester,  April  1973  [M.Sc.  Thesis,  DCS,  1973] 

*  CSRG-26  PSYCHOLOGICAL  COMPLEXITY  OF  COMPUTER  PROGRAMS: 

AN  INITIAL  EXPERIMENT 
Larry  Weissman,  A-ugust  1973 

♦  CSRG-27  STRUCTURED  SUBSETS  OF  THE  PL/I  LANGUAGE 

Richard  C.  Holt  and  David  B.  Wortman,  October  1973 


*  CSRG-28  ON  THE  REDUCED  M?^.TRIX  REPRESENTATION  OF  LR(k) 

PARSER  TABLES 

Marc  Louis  Joliat,  October  1973  [Ph.D,  Thesis,  EE  1973] 

*  CSRG-29  A  STUDENT  PROJECT  FOR  AN  OPERATING  SYSTEMS  COURSE 

B.  Czarnik  and  D.  Tsichritzis  (eds.)  ,  November  1973 

*  CSRG-3C  A  PSEUDO-MACHINE  FOR  CODE  GENERATION 

Henry  John  Pasko,  December  1973  [M.Sc.  Thesis,  DCS  1973] 

*  CSRG-31  AN  ANNOTATED  BIBLIOGRAPHY  ON  COMPUTER  PROGRAM 

ENGINEER  ING 

J.D,  Gannon  (ed. ) ,  Second  Edition,  March  1974 

CSPG-32  SCHEDULING  MULTIPLE  RESOURCE  COMPUTER  SYSTEMS 

E. D.  Lazowska,  May  1974  [M*Sc.  Thesis,  DCS,  1974  ] 

*  CSRG-33  AN  EDUCATIONAL  DATA  BASE  MANAGEMENT  SYSTEM 

F,  Lochovsky  and  D.  Tsichritzis,  May  1974  [INFOR, 
to  appear] 

*  CSRG-34  ALLOCATING  STORAGE  IN  HIERARCHICAL  DATA  BASES 

P.  Bernstein  and  D.  Tsichritzis,  May  1974  [Information 
Systems  Journal,  v.  1 ,  pp.  133-140  ] 

*  CSRG-35  ON  IMPLEMENTATION  OF  RELATIONS 

D.  Tsichritzis,  May  1974 

*  CSRG-36  SIX  PL/I  COMPILERS 

D.  B.  Wortman,  P,  J.  Khaiat,  and  D.M.  Lasker,  August  1974 
[Software  Practice  and  Experience,  v,6,  n.  3, 

July-Sept.  1976] 

*  CSRG-37  A  METHODOLOGY  FOP  STUDYING  THE  PSYCHOLOGICAL  COMPLEXITY 

0^  COMPUTER  PROGRAMS 

Laurence  M,  Weissman,  August  1974 

[Ph.D.  Thesis,  DCS,  1974] 

*  CSRG-38  AN  INVESTIGATION  OF  A  NEW  METHOD  OF  CONSTRUCTING 

SOFTWARE 

David  M.  Lasker,  September  1974  [M.Sc.  Thesis,  DCS,  1974] 

CSEG-39  AN  ALGEBRAIC  MODEL  FOR  STRING  PA.TTERNS 

Glenn  F.  Stewart,  September  1974  [M.Sc.  Thesis,  DCS,  1974] 

*  CSRG-40  EDUCATIONAL  DATA  BASE  SYSTEM  USER’S  MANUAL 

J.  Klebanoff,  F.  Lochovsky,  A*.  Rozitis,  and 
D.  Tsichritzis,  September  1974 

*  CSFG-41  NOTES  FROM  A  WORKSHOP  ON  THE  ATTAINMENT  OF 

RELIABLE  SOFTWARE 

David  B.  Wortman  (ed.),  September  1974 

*  CSRG-42  THE  PROJECT  SUE  SYSTEM  LANGUAGE  REFERENCE  MANUAL 

B.L.  Clark  and  F.J.B.  Ham,  September  1974 


CSRG-43  A  DATA.  BASE  PROCESSOP 

E.A.  Ozkarahan,  S.A.  Schuster  and  K.C,  Smith# 

November  1974  [Proceedings  National  Computer 
Conference  1975#  v,44#  pp, 379-388] 

CSRG-44  MATCHING  PROGRAM  A.ND  DATA  REPRESENTATION  TO  A 

COMPUTING  ENVIRONMENT 

Eric  C.R,  Hehner#  November  1974  [Ph.D.  Thesis#  DCS#  1974] 

CSRG-45  THREE  APPROACHES  TO  RELIABLE  SOFTWARE;  LANGUAGE 

DESIGN#  DYADIC  SPECIFICATION#  COMPLEMENTARY  SEMANTICS 
J. F.  Donahue#  J. D.  Gannon#  J.V.  Guttag  and 
J.J.  Horning#  December  1974 

CSP,G-46  THE  SYNTHESIS  OF  OPTIMAL  DECISION  TREES  FROM 
DECISION  TABLES 

Helmut  Schumacher#  December  1974 
[M.Sc.  Thesis,  DCS#  1974  ] 

CSPG-47  LANGUAGE  DESIGN  TO  ENHANCE  PROGRAMMING  RELIABILITY 

John  D,  Gannon#  January  1975  [Ph.D,  Thesis#  DCS#  1975] 

CSRG,-48  DETERMINISTIC  LEFT  TO  RIGHT  PARSING 

Christopher  J.H.  Turnbull#  January  1975 
[Ph.D.  Thesis#  EE#  1974] 

CSRG-49  A  NETWORK  FRAMEWORK  FOP  RELATIONAL  IMPLEMENTATION 
D,  Tsichritzis,  February  1975  [in  Data  Base 
Description#  Dongue  and  Ni  jssen  (eds.)  ,  North 
Holland  Publishing  Co.] 

CSRG-50  A 'unified  APPROACH  TO  FUNCTIONAL  DEPENDENCIES 
AND  RELATIONS 

P.A.  Bernstein#  J.P.  Swenson  and  D.C.  Tsichritzis 
February  19Y5  [Proceedings  of  the  ACM  SIGMOD  Conference# 
1975  ] 

CSRG-51  ZETA;  A  PROTOTYPE  RELATIONAL  DATA  BASE 
MANAGEMENT  SYSTEM 

M.  Brodie  (ed)  .  February  1975  [Proceedings  Pacific 
ACM  Conference#  1975] 

CSPG-52  AUTOMATIC  GENERATION  OF  SYNTAX -REPAIR  IN G  AND 
PARAGRAPHING  PARSERS 

David  T.  Barnard#  March  1975  [M.Sc.  Thesis#  DCS#  1975] 

CSRG-53  QUERY  EXECUTION  AND  INDEX  SELECTION  FOR  RELATIONAL 
DATA  BASES 

J.H.  Gilles  Farley  and  Stewart  A.  Schuster#  March  1975 

CSRG-54  AN  ANNOTATED  BIBLIOGRAPHY  ON  COMPUTER 
PROGRAM  ENGINEERING 

J.V.  Guttag  (ed.) #  Third  Edition#  April  1975 

CSRG-55  STRUCTURED  SUBSETS  OF  THE  PL/1  LANGUAGE 

Richard  C.  Holt  and  David  B.  Wortman#  May  1975 


CSRG-56  FEATURES  OF  A  CONCEPTUAL  SCHEMA 

D.  Tsichritzis,  June  1975  [Proceedings  Very  Large 
Data  Base  Conference,  1975  ] 

*  CSRG-57  MERLIN:  TOWARDS  AN  IDEAL  PROGRAMMING  LANGUAGE 

Fric  C.R,  Hehner,  July  1975 

CSRG-58  ON  THE  SEMANTICS  OF  THE  RELATIONAL  DATA  MODEL 
Hans  Albrecht  Schmid  and  J.  Richard  Swenson, 

July  1975  [Proceedings  of  the  ACM  SIGMOD  Conference, 
1975] 

*  CSRG-59  THE  SPECIFICATION  AND  APPLICATION  TO  PROGRAMMING 

OF  ABSTRACT  DATA  TYPES 

John  V.  Guttag,  September  1975  [Ph.D.  Thesis,  DCS,  1975 

CSP.G-60  NORMALIZATION  AND  FUNCTIONAL  DEPENDENCIES  IN  THE 
RELATIONAL  DATA  BASE  MODEL 
Phillip  Alan  Bernstein,  October  1975 
[Ph.D.  Thesis,  DCS,  1975] 

*  CSRG-61  LSL:  A  LINK  AND  SELECTION  LANGUAGE 

D,  Tsichritzis,  November  1975  [Proceedings  ACM 
SIGMOD  Conference,  1976] 

*  CSRG-62  COMPLEMENTARY  DEFINITIONS  OF  PROGRAMMING 

LANGUAGE  SEMANTICS 

James  E,  Donahue,  November  1975 

[Ph.D.  Thesis,  DCS,  1975] 

CSRG-63  AN  EXPERIMENTAL  EVALUATION  OF  CHESS  PLAYING 
HEURISTICS 

Lazio  Sugar,  December  1975  [M.Sc.  Thesis,  DCS,  1975] 

CSRG-6a  A  VIRTUAL  MEMORY  SYSTEM  FOR  A  RELATIONAL 
ASSOCIATIVE  PROCESSOR 

S.A.  Schuster,  E.A..  Ozkarahan,  and  K.C.  Smith, 

February  1976  [Proceedings  National  Computer 
Conference  1976,  v.45,  pp.  855-862  ] 

*  CSPG-65  PERFORMANCE  EVALUATION  OF  A  RELATIONAL 

ASSOCIATIVE  PROCESSOR 

E. A.  Ozkarahan,  S.A.  Schuster,  and  K.C.  Sevcik, 

February  1976  [ACM  Transactions  on  Database 
Systems,  v.  1 ,  n:  4,  December  1976  ] 

CSRG-66  EDITING  COMPUTER  ANIMATED  FILM 
Michael  D.  Tilson,  February  1976 
[M.Sc.  Thesis,  DCS,  1975] 

CSRG-67  A  DIAGRAMMATIC  APPROACH  TO  PROGRAMMING  LANGUAGE 
S  EM ANTICS 

James  R.  Cordy,  March  1976  [M.Sc.  Thesis,  DCS,  1976] 

CSRG-68  A  SYNTHETIC  ENGLISH  QUERY  LANGUAGE  FOR  A 
RELATIONAL  ASSOCIATIVE  PROCESSOR 

L.Kerschberg ,  E.A.  Ozkarahan,  and  J.E.S.  Pacheco 
April  1976 


CSPG-69  AN  ANNOTATED  BIBLIOGRAPHY  ON  COMPUTER  PROGRAM  ENGINEERING 

D.  Barnard  and  D.  Thompson  (Eds.),  Fourth  Edition,  May  1976 

*  CSPG-70  A  TAXONOMY  OF  DATA  MODELS 

L.  Kerschberg,  A.  Klug,  and  D.  Tsichritzis,  May  1976 
[Proceedings  Very  Large  Data  Base  Conference,  1976] 

CSRG-71  OPTIMIZATION  FEATURES  FOR  THE  ARCHITECTURE  OF  A 
DATA  BASE  MACHINE 

E. A.  Ozkarahan  and  K.C.  Sevcik,  May  1976 

CSPG-72  THE  RELATIONAL  DATA  BASE  SYSTEM  OMEGA  -  PROGRESS  REPORT 
H.A.  Schmid  (ed.  )  ,  P.A.  Bernstein  (ed.),  B.  Arlow, 

R.  Baker  and  S,  Pozgaj,  July  1976 

CSRG-73  AN  ALGORITHMIC  APPROACH  TO  NORMALIZATION  OF 
RELATIONAL  DATA  BASE  SCHEMAS 
P.A.  Bernstein  and  C.  Beeri,  September  1976 

CSRG-74  A  HIGH-LEVEL  MACHIN  E- OR  lENT  ED  ASSEMBLER  LANGUAGE 
FOR  A  DATA  BASE  MACHINE 

E.A.  Ozkarahan  and  S.A..  Schuster,  October  1976 

CSPG-75  DO  CONSIDERED  OD:  A  CONTRIBUTION  TO  THE 
PROGRAMMING  CALCULUS 
Eric  C.R.  Hehner,  November  1976 

CSRG-76  "SOFTWARE  HUT":  A  COMPUTER  PROGRAM  ENGINEERING 
PROJECT  IN  THE  FORM  OF  A  GAME 
J.J.  Horning  and  D.B.  Wortman,  November  1976 

CSRG-77  A  SHORT  STUDY  OF  PROGRAM  AND  MEMORY  POLICY  BEHAVIOJR 
G,  Scott  Graham,  January  1977 

CSRG-Ve  A  PANACHE  OF  DBMS  IDEAS 

D.  Tsichritzis,  February  1977 

CS^G-79  THE  DESIGN  AND  IMPLEMENTATION  OF  AN  ADVANCED  LALR 
PARSE  TABLE  CONSTRUCTOR 

David  H.  Thompson,  April  1977  [M.Sc.  Thesis,  DCS,  1976] 

CSPG-80  AN  ANNOTATED  BIBLIOGRAPHY  ON  COMPUTER  PROGRAM  ENGINEERING 
D.  Barnard  (Ed.),  Fifth  Edition,  May  1977 

CSRG-81  PROGRAMMING  METHODOLOGY:  AN  ANNOTATED  BIBLIOGRAPHY  FOR 
IFIP  WORKING  GROUP  2.3 

Sol  J.  Greenspan  and  J.J.  Horning  (Eds.) ,  First  Edition, 

May  1977 

CSRG-82  NOTES  ON  EUCLID 

edited  by  W.  David  Elliot  and  David  T.  Barnard, 

August  1977 

CSRG-83  TOPICS  IN  QUEUEING  NETWORK  MODELING 
edited  by  G.  Scott  Graham,  July  1977 

CSPG-8U  TOWARD  PROGRAM  ILLUSTRATION 

Edward  Yarwood,  September  1977  [m.Sc.  Thesis,  DCS,  1974] 


CSRG-85  CHARACTERIZING  SERVICE  TIME  AND  RESPONSE  TIME  DISTRIBUTIONS 
IN  QUEUEING  NETWORK  MODELS  OF  COMPUTER  SYSTEMS 
Edward  D.  Lazowska,  September  1977 
[Ph.D.  Thesis,  DCS,  1977] 

CSRG-86  MEASUREMENTS  OF  COMPUTER  SYSTEMS  FOR 
QUEUEING  NETWORK  MODELS 
Martin  G.  Kienzle,  October  1977 
[M.Sc.  Thesis,  DCS,  1977] 

CSRG-87  »OLGA»  LANGUAGE  REFERENCE  MANUAL 

B.  Abourbih,  H.  Trickey,  D.M,  Lewis,  E.S,  Lee, 

P.I.P.  Boulton,  November  1977 

CSRG-88  USING  A  GRAMMATICAL  FORMALISM  AS  A  PROGRAMMING  LANGUAGE 
Brad  A.  Silverberg,  January  1978 
[M.Sc.  Thesis,  DCS,  1978] 

CSPG-89  ON  THE  IMPLEMENTATION  OF  RELATIONS:  A  KEY  TO  EFFICIENCY 
Joachim  W.  Schmidt,  January  1978 

CSRG-90  DATA  BASE  MANAGEMENT  SYSTEM  USER  PERFORMANCE 
Frederick  H.  Lochovsky,  April  1978 
[Ph.D.  Thesis,  DCS,  1978] 

CSRG-91  SPECIFICATION  AND  VERIFICATION  OF  DATA  EASE 
SEMANTIC  INTEGRITY 

Michael  Lawrence  Brodie,  April  1978 
[Ph.D.  Thesis,  DCS,  1978] 

CSRG-92  ’’STRUCTURED  SOUND  SYNTHESIS  PROJECT  (SSSP)  : 

AN  INTRODUCTION” 

by  William  Buxton,  Guy  Ferdorkow,  with 
Ronald  Baecker,  Gustav  Ciamaga,  Leslie  Mezei 
and  K.C.  Smith,  June  1978 

CSRG-93  ”A  DEVICE-INDEPENDENT, GENERAL-PURPOSE  GRAPHICS 
SYSTEM  IN  A  MINICOMPUTER  TIME-SHARING 
ENVIRONMENT ” 

William  T.  Reeves,  August  1978 
[M.Sc.  Thesis,  DCS,  1976] 
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